elm-optimize-level-2/transformations.md

Overview of Transformations

This is an overview of the transformations for elm-optimize.

Not all of them made the cut, but seeing that a transformation is not as effective as initially thought is really good information.

We got a huge head start because of Robin's article.

Each transformation also has a rough summary of impact.

Applying Functions Directly

Elm wraps functions in an object that tracks how many arguments the function takes(also known as 'arity').

This is so that functions can be partially applied, meaning you can apply a few arguments and get a new function that has those arguments "built in".

The most significant speedups we've seen is in finding places where we can skip the wrapper and call the actual function directly. This happens when you call a function with exactly the number of arguments it needs.

In order to do this, we need to adjust function declarations so that the original function can be called either in the standrd 'wrapped' way, or directly.

before

var MyFunction = F2(function (tag, value) {
        return value;
});

after

var MyFunction_fn = function (tag, value) {
        return value;
}, MyFunction = F2(MyFunction_fn);

Then, if this function is called with `A2, we can unwrap the wrapper and call the function directly.

before

A2(MyFunction, one two)

after

MyFunction_fn(one two)

Results Summary

• Included in elm-optimize tool**
• Potentially large positive effect on speed
• Likley small but positive effect on asset size

This has lead to dramatic speedups in some cases, especially when a large number of smaller functions are called and the overhead of calling twice as many functions is significant.

As well, it has a really interesting characteristic in that it makes the initial size of the generated JS larger, but usually results in a smaller minified asset size.

We generate two definitions for a function, but in most cases a function is either always partially applied, or always called with the full number of arguments.

If a function is always called with the full number of arguments, the minifier can eliminate our wrapped version (F2(MyFunction_fn)) and also eliminate the A2 call, which is explicitly smaller than before.

Passing in Unwrappable Functions to Higher Order Functions

Higher order functions like List.map have a hard time taking advantage of the direct function calls because we don't know the arity of the function within the List.map call.

However, we can figure it out.

If List.map is called with a function that we know has an arity

Making type representation isomorphic

Currently the Elm compiler will generate objects that match the shape of a given type.

Maybe looks like this:

var elm$core$Maybe$Just = function(a) {
  return { $: 0, a: a };
};

var elm$core$Maybe$Nothing = { $: 1 };

However, the V8 engine is likely better able to optimize these objects if they have the same shape.

So, this transformation fills out the rest of the variants with field: null so that they have the same shape.

var elm$core$Maybe$Just = function(a) {
  return { $: 0, a: a };
};

var elm$core$Maybe$Nothing = { $: 1, a: null };

This does require information from the Elm code itself, which we're currently getting through elm-tree-sitter.

Results Summary

• Included
• Has an effect in certain circumstances in browsers using V8(Chrome and Edge). Nothing observable otherwise.
  • Most prominently observed in the Elm Core - sum 300 list of custom types benchmark. Otherwise I didn't notice it.
• No noticable effect on asset size.

Inlining literal list constructors

Before

_List_fromArray(['a', 'b', 'c']);

After, using InlineMode.UsingConsFunc

_List_cons('a', _List_cons('b', _List_cons('c', _List_Nil)));

with InlineMode.UsingLiteralObjects

({ $: 1, a: 'a', b: { $: 1, a: 'b', b: { $: 1, a: 'c', b: _List_Nil } } });

Note - Elm actually had this originally(the literal objects verion)! But there's an issue in Chrome with more than 1000 elements.

There's also tradeoff between asset size and speed.

Also of note, becaue _List_fromArray is used for lists of anything, that it's likely being deoptimized by the javascript compiler.

There may be a nice trade off here of using InlineMode.UsingConsFunc, but only inlining at most 20 elements or something, and then using List_fromArray after that.

Results Summary

Object Update

When updating a record in elm via { record | field = new }, elm runs the following function:

function _Utils_update(oldRecord, updatedFields) {
    var newRecord = {};
    for (var key in oldRecord) {
        newRecord[key] = oldRecord[key];
    }
    for (var key in updatedFields) {
        newRecord[key] = updatedFields[key];
    }
    return newRecord;
}

We tried a few different variations in order to see if we could speed this up.

The trick here is that we need to copy the entire record so that it has a new reference.

So, we can't just do record.field = new in the js.

All of these tricks rely on either the spread operator or Object.assign, both of which are not supported in IE.

Replacing the implementation of _Util_update:

Spread operator

const _Utils_update = (oldRecord, updatedFields) => {
    var newRecord = {...oldRecord};
    
    for (var key in updatedFields) {
        newRecord[key] = updatedFields[key];
    }
    return newRecord;
}

Spread for both

const _Utils_update = (oldRecord, updatedFields) => ({...oldRecord, ...updatedFields});

Use Object.assign

const _Utils_update = (oldRecord, updatedFields) => (Object.assign({}, oldRecord, updatedFields));

Inline the call altogether

At the call site, replace

_Utils_update(old, newFields)

with

Object.assign({}, old, newFields)

Result Summary

• Not included in elm-optimize tool
• Again, all of these tricks rely on either the spread operator or Object.assign, both of which are not supported in IE.
• The most promising approach was inlining the call completely with Object.assign.
  • Gave a 366% boost in chrome!
  • And caused firefox to reduce performance by 50% 😅

Simply creating a new record and copying each field manually is significantly faster than using any for of update.(~2.5x in chrome, and ~10x in firefox). You can do this directly in elm.

updateSingleRecordManually record =
    { one = 87
    , two = record.two
    , three = record.three
    }

It's may be worth exploring automating this transformation. There's a question of how much this affects asset size on larger projects.

However, it's hard to explore without knowing the actual shape of the records being updated.

Inline Equality

If Elm's == is applied to any primitive such as:

• Int
• Float
• String
• Bool

Then we can inline the definition directly as ===.

Right now elm-optimize will infer if something is a primitive if a literal is used.

Results Summary

This check is significant for parsing, though also other checks as well.

Inline String.fromFloat/Int

Before

String$fromFloat(val)

After:

val + ""

Results Summary

Arrowizing Functions

Before

var x = function(x){}

After

var x = (x) => {}

This was done for asset size.

Results Summary

• Not include in the elm-optimize tool
• There does seem to be a slight asset size reduction.
• The inline-functions transformation has a larger shrinking impact on asset size.
• Comes with the caveat that the code will not work on IE

We didn't include this in the first version of the tool because the effect seems to be so modest and carries the risk of breaking things on IE.

We would have to add something like a --modernize or --no-ie flag to the tool, and I really like this tool having no configurability.