Big update to prettier-extension-monkeyc

The optimizer is impressive, thanks for this extension!  I have to say, being familiar with prettier from the JS ecosystem, and based only on reading your extension's name, I had no idea it also contained an optimizer.  The `prettier` naming buries the lead.

I also just learned that you optimize the prg file after compilation, after reading your wiki: https://github.com/markw65/monkeyc-optimizer/wiki/Post-Build-Optimizer  Very cool!

cspotcode said:

I had no idea it also contained an optimizer

Initially, I wrote a prettier plugin, but various people said it was too hard to set up (this is probably a fair point if you're not already using node/npm), so I wrote the extension just to make it easy to setup the plugin.

When I added the optimizer I didn't want a second extension; but yes, in hindsight it might be a lot more obvious what it does if I had done that (or renamed it at least).

I've just published v2.0.67. This fixes a couple of minor bugs, and includes a couple of updates to match new behavior in sdk-6.2.x.

v2.0.68 is out.

It fixes a bug in the post build optimizer that could break array initializers, and also improves the array initializer optimization a little.

It also includes a version of the prettier-plugin thats compatible with [email protected], which will only matter if the prettier extension is updated to include [email protected]

I have three arrays of floats that need to be loaded at watchface initialization. They are not updated by any code, they are constants for calcs. I can use Rez and JsonData but only for watches that support that and only if I don't use background. Declaring them as "var speeds = [38 different floats];" takes a lot of bytecode that makes the code 1.5k larger, Does this array initializer optimizer get around these issues, so I could have them in the .prg initialized?

The array-init optimization saves 7 bytes per element, with an overhead of 22 bytes (so it's only done if there are 4 or more elements). So for an array of 38 floats, it should save 38x7-22, or 244 bytes. The array-init optimization is part of the post build optimizer, which is off by default, so you would need to turn it on (in settings, type "post build" into the search box, and turn on the "Prettier Monkey C: Post Build Optimizer" check box.

So by itself, the array init optimization will only save you about 16% on that array. But generally I'm seeing savings of 10-20% of the total code size across a wide range of open source projects, when using both the source-to-source and the post build optimizer together. So, if you're not already using it, try it! You could easily save 1.5k off a 15k app.

Btw, you mentioned using JsonData when possible. I've done the same in my app, but for watches that don't support it, I use  Rez.Strings, and take a string like "1.2,4.5,27.44", split it on "," and call toFloat() on each string. In my case, despite the parsing overhead, its still a code size win.

Rez.Strings is still a background problem. What is the string length limit? Maybe I can work around the "background can't access Rez" feature.

andyj713 said:

Rez.Strings is still a background problem

Can't you just use the 'scope="background"' attribute? Or is there some other background issue?

andyj713 said:

What is the string length limit?

Not sure, but you definitely won't hit a problem with 38 floats...

andyj713 said:

The string of 38 floats is 400+ bytes, so with parsing code it would be more memory than letting the compiler do it.

Maybe - but if you do the parsing early enough, you'll just have a temporary 400 byte spike while memory use is still low, and then the string will be freed anyway.

andyj713 said:

The background scope works, but it orphans devices

Not clear what you mean by that?