Big update to prettier-extension-monkeyc

FlowState said:

To elaborate on this, the use of a non-local variable involves a symbol lookup, but the use of a local variable does not.

_psx_ said:

I don't think so because I can't see symbol for each local var.

That's what I said:

non-local var => symbol lookup

local var => no symbol lookup

That's why a usage of a non-local variable takes up more memory - the code has to refer to the symbol(s) in the identifier (and any qualifiers), like markw65 pointed out.

I know it but it consumes memory unfortunately and I thought it was good in 'no symbol era '.

there is the difference between lookup in runtime/compiletime.

I CAN see symbol for local var in debug.xml. But probably local vars are on stack, numbered, but 2 bytes it's too much, usually limits is 255 so one byte.

jim_m_58 said:

The tests need to be done with a few different apps while the beta optimization as it saved some thousands of bytes for some, and < 100 bytes for others

Here are three open source projects. The numbers are text-size/data-size for a release build, using the first device listed in the manifest.

https://github.com/HanSolo/digital

• Old-compiler
  • Garmin: 11026 / 2148
  • My optimizer: 9435 / 2132
• New Compiler at O2
  • Garmin: 10154 / 2132
  • My optimizer: 9445 / 2132 

https://github.com/ravenfeld/Connect-IQ-DataField-Speed

• Old-compiler
  • Garmin: 2316/727
  • My optimizer: 1895/727
• New Compiler at O2
  • Garmin: 1978/727
  • My optimizer: 1872/727 

https://github.com/fjbenitog/digital-watch-cas10

• Old-compiler
  • Garmin: 8596/2226
  • My optimizer: 7567/2194
• New Compiler at O2
  • Garmin: 7828/2202 (needed a patch to replace "me" with "self")
  • My optimizer: 7508/2194 

I could do more, but its a bit time consuming, since the only way I know to get these numbers is to run under the simulator, open the memory panel, and then read off the values from there. So although my monkeyc-optimizer is setup to build around 150 different open source projects, getting the size stats is painful. If anyone knows a way to find this (eg from the compiler output with -g), I could automate the process...

****** and respect for you :-)

Either you have a typo above in the HanSolo project's numbers or you found some special cases that probably indicate a bug in Compiler Beta (and/or maybe in the optimizer) because the new compiler generated bigger code than the old one: old+optimizer:9435 vs new+optimizer:9445

_psx_ said:

but 2 bytes it's too much, usually limits is 255 so one byte

Don't forget there's an opcode too. So loading a local needs "LoadLoc <id>". I'm guessing the LoadLoc is 1 byte and the id is one byte. Note that Numbers take 5 bytes per reference. Since the number is 32 bits, or 4 bytes, thats again a 1 byte opcode and 4 byte number. I don't know whether all opcodes are the same size or not...

I've also not checked what happens when you go over 256 locals... presumably the compiler either errors, or falls back to an alternate opcode with a bigger id. Or maybe the variable id is variable-length-encoded, and the first 127 take one byte, the next 16383 take 2 bytes etc.

yes, you can't have more than 255 members/globals/etc.

_psx_ said:

it's very good solution but only for function not used frequently (like onUpdate), because assignment need processor time. But maybe access to local is faster then - tests are needed

Well, this is one of the reasons I made it an optional optimization. But generally, if a global is used two or more times dynamically, its going to be better to use the local. Otoh if the global is only used on some paths, and is used at most once on any given path, then it might be a *bit* slower to use the local.

so eg for something like

if (g) {
  foo(g);
  bar(g);
}

pulling out the local will always be better for both size and speed, whereas for something like

switch (x) {
  case 1: foo(g); break;
  case 2: bar(g); break;
  case 3: baz(); break;
}

pulling out the local will be good for size, roughly breakeven for speed when x is 1 or 2, and worse for speed when x is 3.

Traditional partial redundancy elimination is aimed at speed. It will only put the target expression in a local if the expression was definitely going to be evaluated at least once on every path where the assignment to the local occurs - ie it would do it in the first case, but not the second. On the other hand if you changed the second case to switch on g rather than x, pre would kick in, because now if you get to the switch statement, g is definitely going to be evaluated once, and on two paths will be evaluated twice.

I may implement this as another option. This will still reduce code size where it kicks in, but it will kick in less often.