Board index » delphi » Optimization Tips - ?

Optimization Tips - ?

Got a qustion -

What is better, in terms of speed/memory -
to declare a single global variable (a somewhat large record) in a unit
or to declare several local variables of the same type in a few procedures
of
the very same unit ?

Any other optimization tips ?

Waiting to hear some tips ...
Thank You,
               Idan.

 

Re:Optimization Tips - ?


Quote
> What is better, in terms of speed/memory -
> to declare a single global variable (a somewhat large record) in a unit
> or to declare several local variables of the same type in a few procedures
> of the very same unit ?

   It depends on where you're constrained/restricted.  Declaring
variables locally in subprograms requires that that space be allocated on
the Stack...every time you call the procedure/function.  Thus, there's a
probable performance "hit" when this is done, versus allocation on the
Data Segment (global variable) once when the program starts.  This means
that in cases where frequent calls are made to subprograms with local
data, uses of that data will be less performant than using global data.
   Also, the Stack data is uninitialized, so the subprogram must assign
value(s) to it before it's used - there's no "carry over" of local
variables' contents.
   OTOH, if the data variable is large, you may not want it to be
declared globally - even though access is more efficient - because
there's a 64K limit.  One option is to declare/use local variables (with
the above difficulties), but you can also use pointers and allocate the
data on the Heap.  Doing so imposes a (very) slight performance increase,
because such data is accessed with an extra memory addressing reference.
   Bottom line: I'd opt for the global data, either in the Data Segment
(Var data) or on the Heap via a pointer.

Quote
> Any other optimization tips ?

   There are many, but you'll have to ask specific questions about your
needs, since we don't know your experience or application needs...

Re:Optimization Tips - ?


Mike Copeland schrieb in Nachricht ...

Quote
>> What is better, in terms of speed/memory -
>> to declare a single global variable (a somewhat large record) in a unit
>> or to declare several local variables of the same type in a few procedures
>> of the very same unit ?
>[Explanation: global faster than local (f.i. the complex "enter" instr.)]

How about:  (typed constants)

function VeryFastFunctionWithLocals(Para: TPara): boolean;
const ABigVar: TBigVar =
(((0,0,0),(0,0,0),(0,0,0)),((0,0,0),(0,0,0),(0,0,0)),((0,0,0),(0,0,0),(0,0,0)));
      NextBigVar: array[1..1000] of TBigThing;
begin
  {Now the hot stuff}
  VeryFastFunctionWithLocals := true; { that means it has been called }
end;

--
  If you speak German, please visit my homepage (there you will find two
  pictures of my voxel project, too):
     http://home.t-online.de/home/Matthias.Buechse/

  If you want to see the pictures though and me to create an English home-
  page, vote for it at:
     Matthias.Buec...@T-Online.de

Re:Optimization Tips - ?


Quote
> >> What is better, in terms of speed/memory -
> >> to declare a single global variable (a somewhat large record) in a unit
> >> or to declare several local variables of the same type in a few procedures
> >> of the very same unit ?

> >   It depends on where you're constrained/restricted.  Declaring
> >variables locally in subprograms requires that that space be allocated on
> >the Stack...every time you call the procedure/function.  Thus, there's a
> >probable performance "hit" when this is done, versus allocation on the
> >Data Segment (global variable) once when the program starts.

> This is not really true. The allocation is done with a single SUB
> SP,xxxx instruction. It takes practically no time at all and you cannot
> avoid it unless you get rid of all local variables and other items that
> use stack (string operations, with, etc.)

   What about the push/pop of the Stack - is that a constant, regardless
of how much local data and the parameters?  No variable penalty at all?

Quote

> I you want speed, use ASM, do not worry about such minor issues.

   Well, he wasn't asking to that level, as I read it.  He seems a
newbie...

Quote
> Also unless you use 8088 there is no penalty for accessing local
> variables instead of global ones. However, if you have nested procedures
> then there is penalty in accessing a local variable from an outer
> procedure.

   Yes, (an) additional issue.

Re:Optimization Tips - ?


In article <MPG.120bfcbd87710c00989...@news.primenet.com>,

Quote
Mike Copeland <mrc...@primenet.com> wrote:
>> What is better, in terms of speed/memory -
>> to declare a single global variable (a somewhat large record) in a unit
>> or to declare several local variables of the same type in a few procedures
>> of the very same unit ?

>   It depends on where you're constrained/restricted.  Declaring
>variables locally in subprograms requires that that space be allocated on
>the Stack...every time you call the procedure/function.  Thus, there's a
>probable performance "hit" when this is done, versus allocation on the
>Data Segment (global variable) once when the program starts.

This is not really true. The allocation is done with a single SUB
SP,xxxx instruction. It takes practically no time at all and you cannot
avoid it unless you get rid of all local variables and other items that
use stack (string operations, with, etc.)

I you want speed, use ASM, do not worry about such minor issues.

Also unless you use 8088 there is no penalty for accessing local
variables instead of global ones. However, if you have nested procedures
then there is penalty in accessing a local variable from an outer
procedure.

Osmo

Re:Optimization Tips - ?


Mike Copeland wrote ...
Quote

>   What about the push/pop of the Stack - is that a constant,
regardless
>of how much local data and the parameters?  No variable penalty at

all?

No.  There is no push/pop of the stack concerning local data (the
parameters were not the subject).  Local data is allocated/disposed by
subtracting/adding from/to stack pointer a constant calculated at
compile time.  That's why local data is not initialized and not
returned to the caller in any manner.

--

Raimo Suonio
raimo.suo...@qdlc.fi (remove spam preventing q)

Other Threads