Optimisation decorators

1

It’d be cool if you could annotate internal-only types to minify them (at the expense of not being directly usable from JS). Basically an automated version of @as:-

@minified
type example = {
  someDescriptiveProperty: int,
  otherDescriptiveProperty: int,
}
let empty = {
  someDescriptiveProperty: 0,
  otherDescriptiveProperty: 0,
}

let empty = {a: 0, b: 0}
1 Like
2

What would be the purpose? If it’s for size, then any minifier/gzip takes care of it. Plus, it’d make the output harder to debug.

2 Likes
3

It is for size optimisation. I think the only minifier that can do this is Google Closure Compiler in advanced mode can do this optimisation.

But I’m pretty sure you’d be able to do better too - since GCC has a global mapping for all object keys, but you’d do a per-object mapping, so could end up with shorter names.

4

It’s possible to do this on a per-field basis with @as:

type t = {@as("a") supercalifragilisticexpialidocious: int}

let a = {supercalifragilisticexpialidocious: 1}

var a = {
  a: 1
};

(Edit: Sorry, I just re-read your post, and I had missed that you already mentioned this.)

5

Yeah I know!

Basically an automated version of @as :-

Which is why I suggested it - the plumbing is all already there!

6

Right; sorry I momentarily forgot that most minifiers aren’t that good lol.

Fwiw, historically these compiled to arrays, so were even better in terms of size theoretically. But after we’ve measured we realized it basically made no difference. That and the debuggability and zero learning/runtime overhead of interop (and some perf gains from no bound checking) made us go through with changing them to js objects.

It’s still good to care about output size though.

The @as feature was made for interop reason back when our syntax didn’t have the \"illegal-identifier" feature. You can of course use it to minify but at that point I’d suggest focusing elsewhere, e.g. remove a big dependency, which has a few orders of magnitude bigger ROI.

2 Likes
7

This is something I want to do, but not sure where to draw the line. Since some types maybe exported for FFI

8

I sometimes ponder how this could be achieved, perhaps record annotations as compiler hints? Default to renaming, but with a FFI hint to disable rename? I would also accept only renaming with a hint (but then I’d be littering my codebase with hints).

This hint would also be a useful way to add a "don’t emit optional fields with value None" capability, this is essential for some APIs. The need to remove optional keys is the only reason I still use @deriving(abstract) and @obj.

2 Likes