Awesome
inline-loops.macro
Iteration helpers that inline to native loops for performance
Table of Contents
Summary
inline-loops.macro
is a babel macro that will inline calls to the iteration methods provided, replacing them with for
loops (or for-in
in the case of objects). While this adds more code, it is also considerably more performant than the native versions of these methods. When working in non-JIT environments this is also faster than equivalent runtime helpers, as it avoids function calls and inlines operations when possible.
This is inspired by the work done on babel-plugin-loop-optimizer, but aims to be both more targeted and more full-featured. Rather than globally replace all native calls, the use of macros allow a controlled, opt-in usage. This macro also supports decrementing array and object iteration, as well as nested usage.
You can use it for everything, only for hotpaths, as a replacement for lodash
with legacy support, whatever you see fit for your project. The support should be the same as the support for babel-plugin-macros
.
Usage
import { map, reduce, someObject } from 'inline-loops.macro';
function contrivedExample(array) {
const doubled = map(array, (value) => value * 2);
const doubleObject = reduce(doubled, (object, value) => ({
...object,
[value]: value
}, {});
if (someObject(doubleObject, (value) => value > 100)) {
console.log('I am large!');
}
}
Methods
every
(MDN documentation)everyRight
=> same asevery
, but iterating in reverseeveryObject
=> same asevery
but iterating over objects intead of arrays
filter
(MDN documentation)filterRight
=> same asfilter
, but iterating in reversefilterObject
=> same asfilter
but iterating over objects intead of arrays
find
(MDN documentation)findLast
=> same asfind
, but iterating in reverse (MDN documentation)findObject
=> same asfind
but iterating over objects intead of arrays
findIndex
(MDN documentation)findLastIndex
=> same asfindIndex
, but iterating in reverse (MDN documentation)findKey
=> same asfindIndex
but iterating over objects intead of arrays
flatMap
(MDN documentation)flatMapRight
=> same asflatMap
, but iterating in reverse- There is no object method, as the use cases and expected results are not clearly defined, nor is the expected outcome obvious
forEach
(MDN documentation)forEachRight
=> same asforEach
, but iterating in reverseforEachObject
=> same asforEach
but iterating over objects intead of arrays
map
(MDN documentation)mapRight
=> same asmap
, but iterating in reversemapObject
=> same asmap
but iterating over objects intead of arrays
reduce
(MDN documentation)reduceRight
=> same asreduce
, but iterating in reverse (MDN documentation)reduceObject
=> same asreduce
but iterating over objects intead of arrays
some
(MDN documentation)someRight
=> same assome
, but iterating in reversesomeObject
=> same assome
but iterating over objects intead of arrays
How it works
Internally Babel will transform these calls to their respective loop-driven alternatives. Example
const foo = map(array, fn);
// transforms to
const _length = array.length;
const _results = Array(_length);
for (let _key = 0, _value; _key < _length; ++_key) {
_value = array[_key];
_results[_key] = fn(_value, _key, array);
}
const foo = _results;
If you are passing uncached values as the array or the handler, it will store those values as local variables and execute the same loop based on those variables.
Aggressive inlining
One extra performance boost is that inline-loops
will try to inline the callback operations when possible. For example:
const doubled = map(array, (value) => value * 2);
// transforms to
const _length = array.length;
const _results = Array(_length);
for (let _key = 0, _value; _key < _length; ++_key) {
_value = array[_key];
_results[_key] = _value * 2;
}
const doubled = _results;
Notice that there is no reference to the original function, because it used the return directly. This even works with nested calls!
const isAllTuples = every(array, (tuple) =>
every(tuple, (value) => Array.isArray(value) && value.length === 2),
);
// transforms to
let _determination = true;
for (
let _key = 0, _length = array.length, _tuple, _result;
_key < _length;
++_key
) {
_tuple = array[_key];
let _determination2 = true;
for (
let _key2 = 0, _length2 = _tuple.length, _value, _result2;
_key2 < _length2;
++_key2
) {
_value = _tuple[_key2];
_result2 = Array.isArray(_value) && _value.length === 2;
if (!_result2) {
_determination2 = false;
break;
}
}
_result = _determination2;
if (!_result) {
_determination = false;
break;
}
}
const isAllTuples = _determination;
Conditional / lazy scenarios
There are times where you want to perform the operation lazily, and there is support for this as well:
foo === 'bar' ? array : map(array, (v) => v * 2);
// transforms to
foo === 'bar'
? array
: (() => {
const _length = array.length;
const _results = Array(_length);
for (let _key = 0, _v; _key < _length; ++_key) {
_v = array[_key];
_results[_key] = _v * 2;
}
return _results;
})();
The wrapping in the IIFE (Immediately-Invoked Function Expression) allows for the lazy execution based on the condition, but if that condition is met then it eagerly executes and returns the value. This will work just as easily for default parameters:
function getStuff(array, doubled = map(array, (v) => v * 2)) {
return doubled;
}
// transforms to
function getStuff(
array,
doubled = (() => {
const _length = array.length;
const _results = Array(_length);
for (let _key = 0, _v; _key < _length; ++_key) {
_v = array[_key];
_results[_key] = _v * 2;
}
return _results;
})(),
) {
return doubled;
}
Because there is a small cost to parse, analyze, and execute the function compared to just have the logic in the same closure, the macro will only wrap the logic in an IIFE if such conditional or lazy execution is required.
Bailout scenarios
Inevitably not everything can be inlined, so there are known bailout scenarios:
- When using a cached function reference (we can only inline functions that are statically declared in the macro scope)
- When there are multiple
return
statements (as there is no scope to return from, the conversion of the logic would be highly complex) - When the
return
statement is not top-level (same reason as with multiplereturn
s) - The
this
keyword is used (closure must be maintained to guarantee correct value)
If there is a bailout of an anonymous callback function, that function is stored in the same scope and used in the loop:
const result = map([1, 2, 3], (value) => {
if (value === 2) {
return 82;
}
return value;
});
// transforms to
const _collection = [1, 2, 3];
const _fn = (_value) => {
if (_value === 2) {
return 82;
}
return _value;
};
const _length = _collection.length;
const _results = Array(_length);
for (let _key = 0, _value; _key < _length; ++_key) {
_value = _collection[_key];
_results[_key] = _fn(_value, _key, _collection);
}
const result = _results;
Note that in bailout scenarios that are used in a closure, the transform will wrap itself in an IIFE to avoid memory leaks from retaining the injected variables.
Gotchas
Some aspects of implementing this macro that you should be aware of:
*Object
methods do not perform hasOwnProperty
check
The object methods will do operations in for-in
loop, but will not guard via a hasOwnProperty
check. For example:
// this
const doubled = mapObject(object, (value) => value * 2);
// transforms to this
let _result = {};
let _value;
for (let _key in object) {
_value = object[_key];
_result[key] = _value * 2;
}
const doubled = _result;
This works in a vast majority of cases, as the need for hasOwnProperty
checks are often an edge case; it only matters when using objects created via a custom constructor, iterating over static properties on functions, or other non-standard operations. hasOwnProperty
is a slowdown, but can be especially expensive in legacy browsers or non-JIT environments.
If you need to incorporate this, you can just filter prior to the operation:
const filtered = filterObject(object, (_, key) => Object.hasOwn(object, key));
const doubled = mapObject(filtered, (value) => value * 2);
find*
methods differ in naming convention
Most of the operations follow the same naming conventions:
{method}
(incrementing array){method}Right
(decrementing array){method}Object
(object)
The exception to this is the collection of find
-related methods:
find
findLast
findObject
findIndex
findLastIndex
findKey
The reason for findLast
/ findLastIndex
instead of findRight
/ findIndexRight
is because unlike all the other right-direction methods, those methods are part of the ES spec (findLast
/ findLastIndex
). The reason thatfindKey
is used for object values instead of something like findIndexObject
is because semantically objects have keys instead of indices.
Development
Standard stuff, clone the repo and npm install
dependencies. The npm scripts available:
build
=> runs babel to transform the macro for legacy NodeJS supportclean
=> remove any files fromdist
lint
=> runs ESLint against all files in thesrc
folderlint:fix
=> runslint
, fixing any errors if possibleprepublishOnly
=> runlint
,typecheck
,test
,clean
,and
dist`release
=> release new versionrelease:beta
=> release new beta versiontest
=> run jest teststest:watch
=> runtest
, but with persistent watchertypecheck
=> runtsc
against the codebase