Javascript optimization tips - Revision history

Cholmondely: /* Links */ Added another

2025-02-13T06:31:43Z

‎Links: Added another

Cholmondely: Added Links, sorted out structure

2024-07-02T12:49:45Z

Added Links, sorted out structure

Cholmondely: Cholmondely moved page Optimization tips to Javascript optimization tips: Title too broad and thus consu

2024-06-30T09:09:48Z

Cholmondely moved page Optimization tips to Javascript optimization tips: Title too broad and thus consu

Phkb: /* Quick and easy performance boosts */

2024-04-10T07:47:36Z

‎Quick and easy performance boosts

Phkb: /* Unsorted */

2024-04-10T07:43:10Z

‎Unsorted

Phkb: Updating BB links

2024-02-29T02:21:19Z

Updating BB links

Cholmondely: /* Oolite Javascript Optimization tips */ Added link

2022-10-04T06:28:40Z

‎Oolite Javascript Optimization tips: Added link

Cholmondely: Tagged as Help page

2022-10-03T20:52:42Z

Tagged as Help page

Svengali: added category Oolite

2018-03-25T15:39:43Z

added category Oolite

Astrobe: /* Oolite Javascript Optimization tips */

2017-10-17T17:58:12Z

‎Oolite Javascript Optimization tips

@@ Line 222: / Line 222: @@
 == Links ==
 *[[Logcontrol.plist]] - controls the output to the [[Latest.log]]
 [[Category:Oolite_scripting]] [[Category:Help pages]]

@@ Line 1: / Line 1: @@
 This page collects and (attempts to) organize the tips and findings posted in the [https://bb.oolite.space/viewtopic.php?f=4&t=18837|OXP Performance tips thread]
@@ Line 7: / Line 5: @@
 Measure before optimizing, focus on the parts of the scripts that are called very often. Optimizing the code that deal with ship spawning is nice, but optimizing the code called by addFrameCallback(), which is executed dozens of times per seconds, is more important.
-----
+=== Profiling ===
-Just pointing out the obvious here, but I think it needs to be noted that all these optimization techniquess explained here are not themselves the objective, but the means to get performance. These techniques are not there to jump in and start writing complicated code. They should be used when there is need and where they are needed. And to find this out, the biggest weapon we have is profiling. I fully recommend that before you change anything in your code, you profile it and find out where it really needs attention. Cag already did that and this is the right way to go about it.
+Just pointing out the obvious here, but I think it needs to be noted that all these optimization techniques explained here are not themselves the objective, but the means to get performance. These techniques are not there to jump in and start writing complicated code. They should be used when there is need and where they are needed. And to find this out, the biggest weapon we have is profiling. I fully recommend that before you change anything in your code, you profile it and find out where it really needs attention. Cag already did that and this is the right way to go about it.
 Oolite Test Release writes something in the log header that may have escaped the attention of many, but if you look more carefully, you'll see it: It says: Build options: [...] JavaScript profiling. So you can use Oolite itself to see where bottlenecks in your OXP might be and then you can apply all these techniques exactly where there is a gain to be obtained.
@@ Line 14: / Line 12: @@
 To use the built-in profiler, you need the Debug Console. You just need to run something like :time worldScripts["snoopers"].calcNewDate() or console.profile(function() { [...] }); to get profiling information about the function you want to examine.
 [https://bb.oolite.space/viewtopic.php?f=4&t=18837#p257063|link]
-----
 I wrote a utility that monitors the frame rate in an effort to tailor my code's impact to the player's setup.
 So on a slower machine, I can do less or do it less often or spread the work out over several frames.
 It's called fps_monitor and since I had to learn how, it's an oxz:
-With it, you can track the fps rate, as well as the median, mode, mean, high & low values.
+*With it, you can track the fps rate, as well as the median, mode, mean, high & low values.
-You can set up to 3 time frames and report to the log file and/or the in-game console.
+*You can set up to 3 time frames and report to the log file and/or the in-game console.
-You can access the data from an oxp so as to adjust to current conditions.
+*You can access the data from an oxp so as to adjust to current conditions.
 The readme has several examples of how I'm using it. I'm hoping for some feedback and discussion on using this (or something else) to reclaim our frame rate.
@@ Line 47: / Line 48: @@
 ----
 All Oolite-provided functions which take a vector as an argument may instead be passed an array of three numbers, or an Entity (in which case the entity’s position is used) [emphasis added]
@@ Line 55: / Line 55: @@
 ----
 The properties .heading and .vectorForward are always identical (verified in the source code). And they are always unit vectors, so there's no need to use .direction() on them directly. If your callback uses both, just pick one. .heading is easier to type but .vectorForward is nearer (in Ship vs Entity) and that's one less get in your profile.
 == Memory managment ==
 However, this automatic memory management requires computations to determine which objects are "dead" and which are not. This is done in "garbage collection cycles" that may require significant time and cause a stutter in-game. The more objects a script generates, the more work for the garbage collector. There are some techniques to mitigate this.
@@ Line 219: / Line 219: @@
 ''TODO'': don't know what to do with the second part of [https://bb.oolite.space/viewtopic.php?f=4&t=18837&start=30#p257319|link]
 [[Category:Oolite_scripting]] [[Category:Help pages]]

@@ Line 41: / Line 41: @@
 * Dereferences are costly. A dereference is (well, at least it's why I call them) when you access a property of an object in this fashion:
-thingie.myProperty or thingie['myProperty']
+  thingie.myProperty or thingie['myProperty']
 Save the result in a variable to avoid doing it again.

@@ Line 140: / Line 140: @@
 Code:
-thingie.myProperty or thingie['myProperty']
+  thingie.myProperty or thingie['myProperty']
 Save the result in a variable to avoid doing it again.
@@ Line 153: / Line 153: @@
 * No foreach loops, no for loops. Use this way:
-<nowiki>
+  var z = myArray.length;
-var z = myArray.length;
+  while (z--) {
-while (z--) {
+      var myElement = myArray[z];
-    var myElement = myArray[z];
+      // my code
-    // my code
 This is the quickest way as it caches the array length and compares to zero only.
@@ Line 165: / Line 163: @@
 * the following is faster than indexOf when dealing with arrays:
-<nowiki>
-this._index_in_list = function( item, list ) { // for arrays only
+  this._index_in_list = function( item, list ) { // for arrays only
      var k = list.length;
      while( k-- ) {
@@ Line 172: / Line 170: @@
+     }
      return -1;
-−
+  }
-</nowiki>
 so,
 '''if( targets.indexOf( ship ) ...'''
@@ Line 187: / Line 185: @@
 To speed it more, store separately the filter and the data:
-<nowiki>
+  {dataType: [dataId,...], ...}
-{dataId: data,...}
+  {dataId: data,...}
 This way, you avoid the for...in loop, the hasOwnProperty() check, and of course you avoid iterating on the prototypes' properties.
@@ Line 207: / Line 203: @@
 * never use 'delete' - it's not doing what you'd expect. In shipWillDockWithStation, I see a lot of
-<nowiki>
-if( isValidFrameCallback( this.x) ) {
+  if( isValidFrameCallback( this.x) ) {
-	removeFrameCallback( this.x);
+    removeFrameCallback( this.x);
-	delete this.x;
+    delete this.x;
-−
+  }
-</nowiki>
 where the last line just needs to be
 '''this.x= null;'''

@@ Line 1: / Line 1: @@
 = Oolite Javascript Optimization tips =
-This page collects and (attempts to) organize the tips and findings posted in the [http://www.aegidian.org/bb/viewtopic.php?f=4&t=18837|OXP Performance tips thread]
+This page collects and (attempts to) organize the tips and findings posted in the [https://bb.oolite.space/viewtopic.php?f=4&t=18837|OXP Performance tips thread]
 == Foreword ==
@@ Line 13: / Line 13: @@
 To use the built-in profiler, you need the Debug Console. You just need to run something like :time worldScripts["snoopers"].calcNewDate() or console.profile(function() { [...] }); to get profiling information about the function you want to examine.
-[http://www.aegidian.org/bb/viewtopic.php?f=4&t=18837#p257063|link]
+[https://bb.oolite.space/viewtopic.php?f=4&t=18837#p257063|link]
 ----
 I wrote a utility that monitors the frame rate in an effort to tailor my code's impact to the player's setup.
@@ Line 25: / Line 25: @@
 The readme has several examples of how I'm using it. I'm hoping for some feedback and discussion on using this (or something else) to reclaim our frame rate.
-*[http://www.aegidian.org/bb/viewtopic.php?f=4&t=18837&start=45#p258473| link to the BB post]
+*[https://bb.oolite.space/viewtopic.php?f=4&t=18837&start=45#p258473| link to the BB post]
-*[http://www.aegidian.org/bb/viewtopic.php?f=2&t=16990 Thread on tracking FPS] (2014-16)
+*[https://bb.oolite.space/viewtopic.php?f=2&t=16990 Thread on tracking FPS] (2014-16)
 ----
@@ Line 135: / Line 135: @@
 Src: https://developers.google.com/speed/art ... javascript
-''TODO'' Merge [http://www.aegidian.org/bb/viewtopic.php?f=4&t=18837#p257050|cag's remarks on closures]
+''TODO'' Merge [https://bb.oolite.space/viewtopic.php?f=4&t=18837#p257050|cag's remarks on closures]
 * Dereferences are costly. Minimize cost of dereferences. A dereference is (well, at least it's why I call them) when you access a property of an object in this fashion:
@@ Line 222: / Line 222: @@
 * In oxps, save particularly the native obj-c oolite sub-objects.
-''TODO'': don't know what to do with the second part of [http://www.aegidian.org/bb/viewtopic.php?f=4&t=18837&start=30#p257319|link]
+''TODO'': don't know what to do with the second part of [https://bb.oolite.space/viewtopic.php?f=4&t=18837&start=30#p257319|link]
 [[Category:Oolite_scripting]] [[Category:Help pages]]

← Older revision	Revision as of 09:09, 30 June 2024
(No difference)

← Older revision		Revision as of 20:52, 3 October 2022
Line 223:		Line 223:
	''TODO'': don't know what to do with the second part of [http://www.aegidian.org/bb/viewtopic.php?f=4&t=18837&start=30#p257319\|link]		''TODO'': don't know what to do with the second part of [http://www.aegidian.org/bb/viewtopic.php?f=4&t=18837&start=30#p257319\|link]

−	[[Category:Oolite_scripting]]	+	[[Category:Oolite_scripting]] [[Category:Help pages]]

← Older revision		Revision as of 15:39, 25 March 2018
Line 222:		Line 222:

	''TODO'': don't know what to do with the second part of [http://www.aegidian.org/bb/viewtopic.php?f=4&t=18837&start=30#p257319\|link]		''TODO'': don't know what to do with the second part of [http://www.aegidian.org/bb/viewtopic.php?f=4&t=18837&start=30#p257319\|link]
		+
		+	[[Category:Oolite_scripting]]

← Older revision		Revision as of 17:58, 17 October 2017
Line 56:		Line 56:

	The properties .heading and .vectorForward are always identical (verified in the source code). And they are always unit vectors, so there's no need to use .direction() on them directly. If your callback uses both, just pick one. .heading is easier to type but .vectorForward is nearer (in Ship vs Entity) and that's one less get in your profile.		The properties .heading and .vectorForward are always identical (verified in the source code). And they are always unit vectors, so there's no need to use .direction() on them directly. If your callback uses both, just pick one. .heading is easier to type but .vectorForward is nearer (in Ship vs Entity) and that's one less get in your profile.
		+
		+	== Memory managment ==
		+
		+	Javascript is a garbage collected language. This means that it automatically removes from memory the objects that are no longer used.
		+	However, this automatic memory management requires computations to determine which objects are "dead" and which are not. This is done in "garbage collection cycles" that may require significant time and cause a stutter in-game. The more objects a script generates, the more work for the garbage collector. There are some techniques to mitigate this.
		+
		+	The single most effective thing is to re-use objects whenever possible. Take arrays:
		+	<pre>
		+	mylist = [];
		+	</pre>
		+
		+	... is fine for initializing one but that is the only time this statement should be used. If you're doing this to clear an array (& remove references so objects in the list can be GC'd, a laudable goal), what you're really doing is assigning 'mylist' a brand new, empty array, and if 'mylist' is its only reference, you are succeeding in your goal but only as a side-effect. By assigning '[ ]' to your variable, you're tossing the old array (& all its references) on to the garbage heap. :)
		+
		+	If you want to clear and re-use an array, all you need to do is:
		+	<pre>
		+	mylist.length = 0;
		+	</pre>
		+
		+	and your array will be as empty as it was when it started. And yes, all the references to objects that were in your list are gone and they'll be GC'd. This seems counterintuitive, and there is a lot of debate as to whether this works across all implementations of JS, but is does work in Oolite, which is all we care about.
		+
		+	Before you go and convert all your arrays to this.$variables, remember Day's trick for assigning function references to properties of a function:
		+	<pre>
		+	this._myfunction = function _myfunction() { // NB: the 2nd '_myfunction' names the function, useful in stack dumps and profiling too
		+	var that = _myfunction;
		+	var random = (that.random = that.random \|\| Math.random);
		+	var mylist = (that.mylist = that.mylist \|\| []);
		+
		+	mylist.length = 0;
		+	...
		+	}
		+	</pre>
		+
		+	Now '_myfunction' will re-use the same array each time it's called, not creating a new one every time with mylist = [];
		+
		+	This same trick works for dictionary objects, that some functions require as parameters:
		+
		+	<pre>
		+	var missionConfig = {titleKey: "oolite-contracts-cargo-none-available-title",
		+	messageKey: "oolite-contracts-cargo-none-available-message",
		+	allowInterrupt: true,
		+	screenID: "oolite-contracts-cargo-none",
		+	exitScreen: "GUI_SCREEN_INTERFACES"};
		+	mission.runScreen(missionConfig);
		+	</pre>
		+
		+	This will create a new object every time it's invoked. But if we do the same as above:
		+	<pre>
		+	var missionConfig = (that.missionConfig = that.missionConfig \|\| {});
		+	...
		+	missionConfig.titleKey = "oolite-contracts-cargo-none-available-title";
		+	missionConfig.messageKey = "oolite-contracts-cargo-none-available-message";
		+	missionConfig.allowInterrupt = true;
		+	missionConfig.screenID = "oolite-contracts-cargo-none";
		+	missionConfig.exitScreen = "GUI_SCREEN_INTERFACES";
		+	mission.runScreen(missionConfig);
		+	</pre>
		+
		+	we'll only consume a single object here for the entire game.
		+
		+	There is a function in the debug console, console.writeJSMemoryStats(), that writes out some handy info:
		+	<pre>
		+	JavaScript heap: 19.48 MiB (limit 32.00 MiB, 7 collections to date)
		+	</pre>

	== Unsorted ==		== Unsorted ==