06-03-2018 14:00
06-03-2018 14:00
I'm writing an application that's pushing the limits of the 65K that we have to work with. I haven't had this restriction since I worked on the Commodore 64K (1982?). But I'm not complaining. I think it's unbelievable that we can write programs to run on a watch. I'm having a ball writing, testing and rewriting and retesting and rewriting...
I wasn't being honest when I said it was pushing the 65K limit. I've gone well over it, several times! I'm very familiar with the "out of memory error". In fact, we're best friends. 🙂
During the rewrites, I figured I could use any of a number of tools out there to compress javascript code. Little did I know, they don't work with the flavor of Javascript we're using. 😞
I did, however, find a php program that will minimize the script. It works really well to remove all white space and, especially for me, all the comments. The program can be pulled from git:
https://github.com/matthiasmullie/minify
If anyone knows of a compression tool that works for us, I'd be interested to here about it. I ended up rolling my own, somewhat specific, compression tool. I saved a bunch of memory. Who would have thought that descriptive variable names was a bad thing...
Rich
Answered! Go to the Best Answer.
06-10-2018 21:39
06-10-2018 21:39
> I wondered why the original code, which had virtually no local variables, had a higher peak load.
Probably, because the garbage collection is triggered by 8KB memory allocation (or the heap full event) in JerryScript. That fact mess up a measurements. When you inspect memory.js.used, you’re taking garbage into account as well.