TRUE and #TRUE and 1 are the same speed.
12Me21Created:
This doesn't say anything about them being the same speed though. Perhaps when it occurs in DATA it's a constant, but maybe it's a "variable" otherwise. DATA is especially weird when it comes to constant-handling; it doesn't consider "AAA"*3 or similar to be a "constant expression." Some speed data would help you. I remember testing on the O3DS and they did appear to differ, but not to a degree that actually really mattered.
"AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though. The expression is constant in the sense that its result never changes, unless you run out of memory, the 3DS sets on fire, the world ends or something else.
I think the reason is that a numerical expression will always evaluate to something that takes up 32 or 64 bytes of memory, while a string expression can use a lot more. No reason to fill up the RAM with strings when you don't need to."AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though.
But strings inside the source are already heaped, aren't they? Why waste resources computing the string at runtime (potentially repeatedly) if they're most-likely going to end up being used anyway?I think the reason is that a numerical expression will always evaluate to something that takes up 32 or 64 bytes of memory, while a string expression can use a lot more. No reason to fill up the RAM with strings when you don't need to."AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though.
Because then you have to load ALL strings into memory for the entire time the program is running. You can prove this doesn't happen by doing something like:But strings inside the source are already heaped, aren't they? Why waste resources computing the string at runtime (potentially repeatedly) if they're most-likely going to end up being used anyway?I think the reason is that a numerical expression will always evaluate to something that takes up 32 or 64 bytes of memory, while a string expression can use a lot more. No reason to fill up the RAM with strings when you don't need to."AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though.
END A$="A"*10000000removing the END causes an out of memory error, showing that string expressions aren't evaluated until they are reached
Assuming the code literals and heap are stored in a different space, this isn't as bad a problem. IIRC some basic bytecode structures have a notation likeBecause then you have to load ALL strings into memory for the entire time the program is running. You can prove this doesn't happen by doing something like:But strings inside the source are already heaped, aren't they? Why waste resources computing the string at runtime (potentially repeatedly) if they're most-likely going to end up being used anyway?I think the reason is that a numerical expression will always evaluate to something that takes up 32 or 64 bytes of memory, while a string expression can use a lot more. No reason to fill up the RAM with strings when you don't need to."AAA"*3 isn't a constant since only numerical expressions are pre-evaluated.No reason this should be the case. If you're already optimizing numeric expressions, then you're already doing a bit more than static analysis and you could totally optimize this, I think. Could be wrong though.END A$="A"*10000000removing the END causes an out of memory error, showing that string expressions aren't evaluated until they are reached
LITERAL STRING VALUE ENDor something to that effect, which push the value to the stack or heap or whatever. It DOES inflate your bytecode size though.