Could be useful to force old 16 byte way via some define
Yes, good point...
Can it take more memory in some cases?
Yes... The main ones I can think of are:
Arrays with numbers between -32768 and 32767 would be able to pack both the index and value into one variable. Now that number is lower - I guess between -2048 and 2047 on most boards.
Non-flat strings aren't quite as efficient now. Each extra bit of string has an overhead of 4 bytes, so now the blocks are smaller it's roughly 30% overhead, not 25%.
However in reality I don't think much of that matters. Any String that you actually allocate in one chunk that's big enough gets turned into a flat string now, where the overhead is just one JsVar of 13 bytes (where previously it was 16 bytes).
And generally if you're storing a lot of numbers in an array you should probably have been using typed arrays anyway :)
can we have one or two more bits for array size so typed arrays over 64k are possible
Can you file an issue for this? I think worst case I should be able to add some bits from JsVarDataArrayBufferViewType to get us up to 256k.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Yes, good point...
Yes... The main ones I can think of are:
However in reality I don't think much of that matters. Any String that you actually allocate in one chunk that's big enough gets turned into a flat string now, where the overhead is just one JsVar of 13 bytes (where previously it was 16 bytes).
And generally if you're storing a lot of numbers in an array you should probably have been using typed arrays anyway :)
Can you file an issue for this? I think worst case I should be able to add some bits from
JsVarDataArrayBufferViewType
to get us up to 256k.