-
Notifications
You must be signed in to change notification settings - Fork 62
Performance Advice
Higgs is an optimizing JIT compiler. Writing code that performs best on Higgs requires an understanding of the capabilities of the said compiler. Some uses of the JavaScript language are much more difficult or impossible for Higgs to effectively optimize. This page condenses advice to write better performing code. The advice provided may be similar in part to the advice given for writing efficient code for SpiderMonkey or V8, but much of it is based features and limitations that are specific to Higgs.
Objects are central to JavaScript, as such, every high-performance JIT attempts to optimize object property access. The objects in JavaScript are implemented using a system of shapes (also known as hidden classes). This makes reading and writing to properties much faster than if objects were implemented using dictionaries (hash maps).
Using objects as if they were dictionaries is unfortunately very slow in Higgs. If you require a dictionary or a set, we recommend that you look into the Map and Set classes. You should also avoid deleting properties of objects. Enumerating properties of objects using the for-in loop is supported, but very slow. Therefore, you should avoid using this feature in performance-critical code.
Higgs implements a kind of type inference mechanism. For this reason, it may be more efficient to make it a given property always remains of the same type (e.g.: always an integer, or always a string). Floating-point properties should ideally be initialized to 0.0 (floating-point zero) instead of 0 (integer zero).
In Higgs, global variables are properties of the global object. As such, the same performance advice that applies to regular objects applies to globals. That is, you should avoid deleting global properties or changing their type if possible. In addition to this, Higgs is able to take advantage of the fact that global constants can be resolved at compilation time. Hence, if a global value is a constant, you should mark it as such using Object.defineProperty with the attributes writable and configurable attributes set to false.
In general, function calls are relatively slow. At the time of this writing, Higgs only inlines runtime library calls and nothing else. Hence, for highly performance-critical code, function calls should be avoided if possible. What is particularly important to avoid is multi-layer abstraction patterns involving several levels of function calls.
Creating closures, that is nested functions that capture local variables of parent functions, allocates a function object on the heap. As such, you should ideally allocate closures once and reuse them, and avoid allocating new closures very frequently, particularly in performance-critical code.
Higgs does not support array holes (deleting items in the middle of arrays). For performance, it is better to fill arrays starting from index 0, and to keep the types of array elements uniform (e.g.: all integers or all strings or all objects of the same shape). For efficiency, we recommend that you set the length of an array at creation time (e.g.: new Array(100)) instead of "growing" the array by writing past the end of it.
Higgs now implements ropes to optimize iterative string appending using the += operator. Concatenations are delayed and performed lazily when the concatenated string needs to be accessed. Note that at the time of this writing, only string appending, but not prepending, is optimized in this manner.