Do Arrays use more memory than single variables?

BlitzMax Forums/BlitzMax Beginners Area/Do Arrays use more memory than single variables?

Leiden

(Posted 2005) [#1]

Hope someone can answer this, for instance would an array of MyArray[3] use more memory than just having three variables MyVar_A, MyVar_B, and MyVar_C? Plus how much extra memory (if it does) does it use.

Who was John Galt?

(Posted 2005) [#2]

Probably something like an extra 4 bytes or maybe 8 - But this is fixed no matter if your array has 10 elements or 10,000. Not worth worrying about.

FlameDuck

(Posted 2005) [#3]

Print MemAlloced()
Local myArray[3]
Print MemAlloced()
Local myVar1 , myVar2 , myVar3
Print MemAlloced()

Looks like it.

tonyg

(Posted 2005) [#4]

Is this interesting?

Print MemAlloced()
Print MemAlloced()
Local myVar1 , myVar2 , myVar3
Print MemAlloced()

If memalloced command takes 20 (bytes?) of mem then why don't the variables use anything?

TomToad

(Posted 2005) [#5]

tonyg, try

Flushmem()
Print MemAlloced()
FlushMem()
Print MemAlloced()
Local myVar1, myVar2, myVar3
FlushMem()
Print MemAlloced()

seems MemAlloced uses memory that isn't released until Flushmem() is called.

tonyg

(Posted 2005) [#6]

That's right but if you take out the 'print memalloced' memory usage there is 0 for the variables. If you do the same test with an array it *does* use memory.
Even if I value the variable it doesn't seem to use any memory. I could be misreading this.

Leiden

(Posted 2005) [#7]

I just tested: an array[3] takes 58 bytes and the three variables together only use 22 bytes. So using arrays effectively doubles the what-would-be memory usage. Anyone get similar findings?

tonyg

(Posted 2005) [#8]

Array[3] takes 36 bytes and the variables together take nothing(?)

Hotcakes

(Posted 2005) [#9]

The variables are initialised at init time, before your first command can be executed. The arrays are allocated during run time, when you expect them to be initialised using your code. That explains why the Local line causes no memory loss.

tonyg

(Posted 2005) [#10]

So when we check memory usage of programs it's not reporting any memory used by variables?

Hotcakes

(Posted 2005) [#11]

There's probably exceptions, but for the most part I think variables always take up ram since the birth of the program's existance. 4 or 8 bytes or something each probably.

Leiden

(Posted 2005) [#12]

If its anything like C then it would be a 4 byte pointer to a memory address wouldnt it? In my code (to get my results above) I casted each as an Integer. I havnt checked the results without casting,

Print MemAlloced()
Local MyArray:Int[3]
Print MemAlloced()
Local A1:Int, A2:Int, A3:Int
Print MemAlloced()

tonyg

(Posted 2005) [#13]

That still doesn't show any memory being used by the variables even if they hold a value.

Hotcakes

(Posted 2005) [#14]

Leiden, you're probably right - 4 byte pointer + 4 byte Int (or 8 byte double/1 byte Byte) = a range between 5 and 12 bytes. Theoretically. Anything could be going on under the hood.

Leiden

(Posted 2005) [#15]

So there isnt any way to get the amount of memory being used under the hood then?

Hotcakes

(Posted 2005) [#16]

Not that I know of. I should stress that I'm only hypotheticising here, I don't profess to know anything about... well, anything.

As for what goes on under the hood, well that will become clearer to all once the compiler is opensourced.

Nelvin

(Posted 2005) [#17]

An array needs some internal memory too - the heap manager has to manage the allocated blocks for your array somehow.
The array itself needs the number of bytes you decided it to consume *and* an internal memblockheader (8 bytes IIRC) *AND* you need an additional pointer (4byte) for accessing the array (accessing an array is slower than membervariables too because it's simply more to do and there's a huge potential for cache misses which will make your arrayaccess 10, 20times slower than reading a member variable - please note that this is typically not the case in 10lines of benchmarkcode, but very much in reallife situations)

Last but not least - non object variables (ints, floats etc) do not need any memory because they'r "allocated" on the stack not the heap.

Leiden

(Posted 2005) [#18]

Ahh thanks for that. So if I followed you on that correctly there is a 4 byte accessor to the array, but the accessor is slower than using a membervalue. So I thought that BlitzMax would be doing everything the optimal way? I'm honestly dont have a clue what a membervariable is, can you explain that one please?

Hotcakes

(Posted 2005) [#19]

I think he meant memory variable. =]

Leiden

(Posted 2005) [#20]

Ohh thanks, So does that mean that BlitzMax isnt doing arrays the optimal way?

FlameDuck

(Posted 2005) [#21]

Last but not least - non object variables (ints, floats etc) do not need any memory because they'r "allocated" on the stack not the heap.

True. However shouldn't it be the same for an array of simple datatypes? What about Global Ints, Floats, etc. Shouldn't they be allocated on the heap aswell? They don't use any additional memory.

Ohh thanks, So does that mean that BlitzMax isnt doing arrays the optimal way?

No.

Koriolis

(Posted 2005) [#22]

If I'm not mistaken a one dimension array takes 24 bytes + the array data (by example 4 bytes per slot in an int array). For a 2 dimension array that would be 28 bytes + the array data, and so on.

True. However shouldn't it be the same for an array of simple datatypes

No because Arrays in BlitzMax are true objects, though handled very specially.

Shouldn't they be allocated on the heap aswell? They don't use any additional memory.

Err, What? No. Not sure to see what you meant, but when you have a global array it should still be allocated on the heap. It's the reference to the array object that is global and statically allocated, the object should be allocated on the heap, or else you'd never be able to make it point to a bigger or smaller array.

Nelvin

(Posted 2005) [#23]

@FlameDuck
Global values which only need a onetime init will typically end in some kind of data area in memory - locals have to be initialized whenever they come into scope - but both won't change the memory allocated dynamically.
And as Koriolis wrote - it's because an array is some dynamic object.

@ LeidenK
They are slower because there are 2 steps necessary to read a value instead of only one for reading a variable.

Try to imagine it - accessing a variable is like ... looking at a sheet of paper, you only have to look on it and see what is written on it - accessing an array is like you have a book and a page number - now to get your information you first have to take that book, open your indexed page and then read what's written on it.

It of course depends on the environment, if you have some 100 oder 1000 reads it wont be noticable, but if your app/game is a real number cruncher accessing arrays maybe millions of times a second it may very well make a difference - especially for simple calculations.

FlameDuck

(Posted 2005) [#24]

And as Koriolis wrote - it's because an array is some dynamic object.

Yeah that makes sense.

Leiden

(Posted 2005) [#25]

Nelvin: You example helped me to understand how Arrays are accessed. Thnx! :)

I suppose that using arrays for the time being isnt going to be an issue. Its too much of a hastle to not use them as they provide a simple, compact way to store multiple values under one name. Plus with todays processors it wont make much difference.

Hotcakes

(Posted 2005) [#26]

Which is precisely why they exist. =]

Leiden

(Posted 2005) [#27]

Hehe good point ;)