[fpc-devel] Need heap manager -gv explanation

[Sergei Gorelkin]

28.04.2014 23:14, Petr Kristan пишет:
> On Mon, Apr 28, 2014 at 06:12:18PM +0200, Tomas Hajny wrote:
>> On Mon, April 28, 2014 17:56, Mattias Gaertner wrote:
>>> On Mon, 28 Apr 2014 17:20:17 +0200
>>> Petr Kristan <petr.kristan at epos.cz> wrote:
>>>
>>>> Hi
>>>>
>>>> I have some application with huge usage ReAllocMem and I found the big
>>>> performance difference if application is compiled with -gv option (cca
>>>> 20x faster) then without -gv option.
>>>
>>> -gv generates code for valgrind.
>>> It should be slower with -gv.
>>>
>>>> I suspect fpc heap manager. Is possible to tune fpc heap manager?
>>>> Is some difference in heap manager if application is comiled with -gv or
>>>> without -gv option?
>>
>> Use of valgrind requires/triggers use of cmem. Depending on the particular
>> use case (and potentially also the target platform), cmem may indeed be
>> faster.
> Platform is x86_64 Linux.
>
>> Others would be better positioned for more detailed comparison among
>> various heap managers with regard to speed in different use cases, overall
>> memory requirements achieved by reuse of previously allocated memory, etc.
> Reuse of previously allocated memory - it really can be my problem.
> Here is about 200x call ReAllocMem increasing buffer from 4kB to 80MB.
>
> It looks like as buffer is increasing ReAllocMem is slowing.
> But I must verify this feeling.
>
-gv switch in command line disables the optimized i386 Move procedure (and that's basically the only 
thing it does), so it indeed should cause slowdown. Comments say that valgrind (some pretty old 
version of it) is unable to handle the optimizied Move code. In the meantime, valgrind was 
presumably fixed. At least since my involvement with FPC back in 2005 I was able to use valgrind to 
profile programs without any trouble, and without recompiling them with -gv.
So maybe it's time reconsider the action of -gv switch, or to remove it altogether.

Regards,
Sergei