On 14/01/2015 17:58, Peter Below wrote:
> Gerald Holdsworth wrote:
>
>> On 14/01/2015 14:48, Uwe Raabe wrote:
>>> Gerald Holdsworth wrote:
>>>
>>>> I know
>>>> these days, 800KB in nothing (when most PCs have in excess of 1GB
>> of >> RAM).
>>>
>>> It might be of interest here as a static array as a local variable
>>> inside a procedure is allocated from the stack while a dynamic
>>> array is allocated from the heap.
>>
>> Does that mean that something on the stack is 'dumped' after finished
>> with (i.e. procedure exit), while something from the heap isn't?
>
> Yes, but more importantly the stack is of a fairly limited size (only 1
> MByte per thread as default). Allocating a large static array from the
> stack can result in stack overflow errors (which terminate a program
> immediately). Writing beyond the bounds of a stack-based static array
> is also a wonderful source of hard to track run-time errors.

That explains an error I got when I increased the size of a static local 
array to 800K.

Cheers,

Gerald.

Gerald wrote:

> size:=FileSize(F);
> if size>Length(data) then size:=Length(data);

You can use Min() instead:

{code}
size := Min(FileSize(F), Length(data));
{code}

> Obviously, I should be able to change the 4th line to be
> SetLength(data,size)

That is OK for small files, but I would not recommend itfor large files. 
 Large files should be processed using smaller fixed chunks or a memory mapping.

--
Remy Lebeau (TeamB)

Peter wrote:

> Yes, but more importantly the stack is of a fairly limited size (only
> 1 MByte per thread as default). Allocating a large static array from
> the stack can result in stack overflow errors (which terminate a
> program immediately). Writing beyond the bounds of a stack-based
> static array is also a wonderful source of hard to track run-time
> errors.

As well as a security risk that introduces oppurtunities for buffer overflow 
attacks.

--
Remy Lebeau (TeamB)

Gerald Holdsworth wrote:

> On 14/01/2015 14:48, Uwe Raabe wrote:
> > Gerald Holdsworth wrote:
> > 
> >> I know
> >> these days, 800KB in nothing (when most PCs have in excess of 1GB
> of >> RAM).
> > 
> > It might be of interest here as a static array as a local variable
> > inside a procedure is allocated from the stack while a dynamic
> > array is allocated from the heap.
> 
> Does that mean that something on the stack is 'dumped' after finished 
> with (i.e. procedure exit), while something from the heap isn't?

Yes, but more importantly the stack is of a fairly limited size (only 1
MByte per thread as default). Allocating a large static array from the
stack can result in stack overflow errors (which terminate a program
immediately). Writing beyond the bounds of a stack-based static array
is also a wonderful source of hard to track run-time errors.



-- 
Peter Below (TeamB)

Gerald,

| Obviously, I should be able to change the 4th line to be 
| SetLength(data,size)

True,... just as long as the data over the current array size is no
longer required.  If the new data-size is smaller than the current
DynArray size the items beyond the new data-size will be lost.

One of the great things about DynArrays is that if re-sizing to
increasing data-sizes all current data is automatically retained!!!

-- 

   Q 

1.19.1.372  (Q's Broken Toolbar.)

On 14/01/2015 14:48, Uwe Raabe wrote:
> Gerald Holdsworth wrote:
>
>> I know
>> these days, 800KB in nothing (when most PCs have in excess of 1GB of
>> RAM).
>
> It might be of interest here as a static array as a local variable
> inside a procedure is allocated from the stack while a dynamic array is
> allocated from the heap.

Does that mean that something on the stack is 'dumped' after finished 
with (i.e. procedure exit), while something from the heap isn't?

Cheers,

Gerald.

On 14/01/2015 11:59, Jeff Dyer wrote:
> Firstly, 0..819200 is 819201 bytes - there save you a byte!
>
> But seriously you should use dynamic arrays and make use of the Low() and High() functions to make it easier.
>
> If you are reading from a file, the extra time needed to resize the array will be negligible.

That's good - I've currently use the following method:
   AssignFile(F,filename);
   Reset(F,1);
   size:=FileSize(F);
   if size>Length(data) then size:=Length(data);
   BlockRead(F,data,size,amt);
   CloseFile(F);

Obviously, I should be able to change the 4th line to be 
SetLength(data,size)

>
> In any case, you may need a bigger array in future, so why not make it flexible from the start.

That's what I was thinking.

Cheers,

Gerald.

Gerald Holdsworth wrote:

> I know
> these days, 800KB in nothing (when most PCs have in excess of 1GB of
> RAM).

It might be of interest here as a static array as a local variable
inside a procedure is allocated from the stack while a dynamic array is
allocated from the heap.


-- 
Uwe Raabe
Embarcadero MVP

Firstly, 0..819200 is 819201 bytes - there save you a byte!

But seriously you should use dynamic arrays and make use of the Low() and High() functions to make it easier.

If you are reading from a file, the extra time needed to resize the array will be negligible.

In any case, you may need a bigger array in future, so why not make it flexible from the start.

> {quote:title=Gerald Holdsworth wrote:}{quote}
> Hi all,
> 
> Just a quick query - which is better, in terms of speed and memory 
> usage: a static or a dynamic array.
> 
> For example, consider
> 
>   data: array[0..819200] of Byte;
> 
> where we might only use 9760 bytes on some occasions, but may use the 
> full 819200 on others, or:
> 
>   data: array of Byte;
> 
> and then SetLength(data,9760) or SetLength(data,819200)...or any other 
> size, depending on the size of the file being loaded. I know these days, 
> 800KB in nothing (when most PCs have in excess of 1GB of RAM).
> 
> Cheers,
> 
> Gerald.