-
Thr 2017.02.23
Comments outside functions won't use space, but comments inside will.
That is a key piece I was after, and answers what would have been my next question. Thank you.
Curious why function comments are preserved during save(). Is the limiting factor the amount of space the interpreter and minification engine take up and/or the number of additional pass(es) penalty needed to pre-parse and remove embedded comments?
I'm starting to believe the reason in my save code example, the number of bytes kept increasing despite removing lines of code was that the existing state machine for the embedded comments was derailed when using a block comment around existing code containing a line comment, and/or when mixed languages contained embedded escape chars. Not finding the true end-of-comment kept piling up chars as code, eventually exceeding the available space required for the save.
Just realized, it's more likely the complexity of the state engine in attempting to retain actual code. Hadn't meant that to sound nit-picky as we realize what an undertaking it is to create a software machine. You should be quite proud of what you have accomplished as much as we are mesmorized over what we wish we could do. It is this quality that has allowed the Espruino brand to cultivate this growing community.
Gordon, Thank you for all your effort.
This might be handy? http://www.espruino.com/Performance
Using
Save on send
in the IDE will write the raw JS code to the device, so your changes to the number of characters will have a direct effect.Using the normal
save()
saves (and compresses) an image of memory to flash. It means that if you define things like arrays, they'll take up significant amounts of memory. Comments outside functions won't use space, but comments inside will.But because it's compressed the amount of memory taken up is virtually impossible to know beforehand - if something happens and data is re-arranged in memory then even that can effect the compression