So I was wrong and it is nice because I tended to avoid local vars
declarations :-) But I remember having read somewhere that
using/accessing local vars was slower than global ones and this why I
>> WM> Variables on the stack does not consume time. Only if something has to
>> WM> be initialized or so, like for example a long string.
>> I am not sure that is consume no time. If I remember well, local vars
>> are dynamicaly allocated and deallocated each time you go into the
>> procedure, so it take a bit (not much) to allocate/deallocate it and
>> finally you may produce more memory fragmentation.
FP> Defenitely not. Wilfried is perfectly correct. Allocating only one or one
FP> hundred local variables takes exactly the same time, just the time to add a
FP> constant (computed at compile time) to the stack pointer. It doesn't
FP> fragment memory at all since the local variables are allocated on the stack
FP> and not on the heap managed by the memory allocator.
FP> The only problem with local variable, is that data must be copied elsewhere
FP> if it has to persist for some time after the function returns. And that
FP> takes a lot of time (I mean copy data) when data is a large buffer.
FP> [EMAIL PROTECTED]
To unsubscribe or change your settings for TWSocket mailing list
please goto http://www.elists.org/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be