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.kris...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
