From: Olly
SizeOf is not dynamic, aka it wont work on dynamic arrays (and strings) you can try it with this;
var
ints: array [0..9999] of Integer;
ints2: TIntegerArray;
begin
SetLength(ints2, 9999);
Writeln(SizeOf(ints2));
Writeln(SizeOf(ints));
end;
Ahh that explains why changing length didnt change the sizeof result…
From: slacky
1. Strings and arrays are pointers to some memory. SizeOf will then return the size of the pointer, which on 32bit is 4 bytes, and on 64bit (simba) is 8 bytes.
To get the number of bytes allocated for some 1D array you can do this:
Size := Length(Arr)*SizeOf(Arr[0])
And for string types (AnsiString, WideString, UnicodeString etc):
Size := Length(Str)*SizeOf(Str[1])
Tho, AnsiString, and AnsiChar arrays are 1 byte per element, so the number of bytes used in those is equal to their length.
However if you have declared a constant array or string, for example:
var str:String[10];
then SizeOf will tell you that it's 11 bytes, as it known at compile-time.
2. In any compiled language that will depend on several factors. And still the difference is microscopic.
- In Lape as it's interpreted any real difference will not be noteable, use whatever fits the task.
3. Yes, unused methods takes up some amount of space. Size depends. All the variables (their sizes) and the size of all the instructions in the method. etc…
Btw: Do you have an issue with using Google? A few searches should probably give you the answers you need. Even tho some of this is directly lape-related, it doesn't change much from other compilers.
Dgby taught me to do sth like length * arr[0] while trying to compare 2 arrays…now i finally understand exactly what's going on….
Thanks for the explanation!
I didnt google because i was worried that other languages/compilers differ from simba/lape so i might just be getting the wrong ideas…
From: Brandon
For 2 and 3:
No and Yes. No it makes no difference for Simba because it's interpreted and everything is pushed through a stack and parsed manually.. It doesn't go through the buses directly. It doesn't get stored in registers or anything directly. You're not writing for embedded systems so don't worry about it. You're writing a script. Not assembly or low level code. You're more likely to have cache problems irl compared to size problems and memory constraints (depends). For scripts, just worry about making your own code efficient and like Slacky said, use whatever fits.
Yes (all methods take memory regardless of whether they are un-used or empty) because it is interpreted and there's no optimiser (as done in JIT cases). O2, O3, O4, OFast, Os, etc.. do not exist in Simba. Any code you write, is as optimised as much as you manually did it.. If you did none, there is none. It would probably take longer to compile since it has parse that every time you hit play (though it's negligible). In a compiled language, it would remove it completely from the executable and generate the final binary.
TDLR: Just code.. make your stuff efficient and don't worry about finer/minor details.
Seems like i have to revamp the entire include and take out every method that i have never used…
I'm running several instances of simba so even a 10mb increase per simba makes quite a significant difference.
Right now each simba would take about 60-70MB and sometimes goes up to 100-200mb+ after a few days of running…i have no idea why it increases since i'm pretty sure there's no leak in my code…
Also when i run a clean simba the memory usage increase from about 9mb to 25mb. Is this 16mb increase mostly due to the inbuilt simba methods/variables? So if i remove unused methods from simba and recompile it i could reduce yet another 10mb+ per simba?
It's always the 3 of you that answer my incessant questions…really appreciates the help, would have repped all if i'm able to (
http://puu.sh/cR1j7/ac354e3955.png)..