> On Sep 12, 2017, at 2:35 AM, Sven Barth via fpc-pascal > <fpc-pascal@lists.freepascal.org> wrote: > > I've rechecked and the thing is as follows: > - the IncLocked call happens each time you assign a dynamic array to > another dynamic array variable or a by-value parameter (this also > includes being part of a record, but not a class instance or TP-style > object) > - the DecLocked call happens each time the array is cleared (as long as > the reference count is > 0 this only means a decrement of the count) > which happens if you assign Nil, assign a different array (the > destination array is "cleared") or if the array variable goes out of scope > > The two routines are also used in context of Ansi- and UnicodeString > variables as well as reference counted interfaces (aka COM-style > interfaces). > > In contrast to what I wrote earlier the compiler does however not ensure > a unique array if you only change an element, so given the following > example:
I removed the dynamic arrays from the my code and replaced with static arrays which fixed the performance problem I was having. It’s still not clear when this was being called (how could I track in the debugger?) but I consider this a pretty serious bug and I wouldn’t use dynamic arrays in high performance code. If I had to guess I would say it was from SetLength but 16%? When I replaced with static arrays and used ReAllocMem instead this didn’t happen so what are those 2 functions doing to eat up so much CPU? Regards, Ryan Joseph _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal