[fpc-pascal] Inclocked/declocked

[Sven Barth]

Am 12.09.2017 06:54 schrieb "Ryan Joseph" <ryan at thealchemistguild.com>:
>
>
> > On Sep 12, 2017, at 2:35 AM, Sven Barth via fpc-pascal <
fpc-pascal at 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.

Dynamic arrays are a fairly high level construct. The general advice for
them is not to repeatedly grow (or shrink) them by miniscule amounts, but
mainly by twice the current length. (Don't know if you've been doing that)

> 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?

The Inc-/DecLocked routines perform a locked increment/decrement, so
they're blocking the memory bus for all cores (simply spoken), thus leading
to a higher CPU utilization. On e.g. i386 there is an optimisation to only
do that locking if IsMultiThread is True (some other platforms might
benefit from that optimization as well :/ ).
Additionally they are the leave routines of the dynamic array management
code, so the time would be really used up there if not for the locking.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20170912/d9733e31/attachment.html>