Hello FPC-Pascal,

I'm using FPC 2.2.2 running over WinXP SP2. Are there any technical reasons that expains that a program runs faster using all checks ( I/O, Range, Overflow, Stack and Verify calls ) with optimization level 1 and using heaptrace, than the same one compiled without any check, optimization level 2 or 3 and not using heaptrace ?

I had expected around a 5% faster with the non-checks config, but I get a 2% slower program :-?

Everything has been tested using Lazarus 1 month SVN, using a 1 minute runtime check.

Perhaps bugs in the optimizer, I usually get MUCH faster code with optimization. Well... depending on the code. You can try examining the assembler output (-a compiler switch, -alnrt for more informative output).

Hello leledumbo,

Friday, January 23, 2009, 7:55:28 AM, you wrote:

l> Perhaps bugs in the optimizer, I usually get MUCH faster code with l> optimization. Well... depending on the code. You can try examining the l> assembler output (-a compiler switch, -alnrt for more informative output).

I had done it, but the assembler output does not help too much as the .s files are 4 megabytes :) and the performance loose is somehow distributed around all the code.

My last test is even worst, same settings except the heaptrace, better performance with heaptrace activated :-? I think that I must check that Lazarus is passing all parameters well to fpc...

Perhaps your level 1 code fits in level 1-2 cache, and your level 2-3 don't, causing more cache misses. Try to compile with -Os instead level 1-2-3 and see if it's faster.

Hello Eduardo,

EM> Perhaps your level 1 code fits in level 1-2 cache, and your level 2-3 EM> don't, causing more cache misses. Try to compile with -Os instead EM> level 1-2-3 and see if it's faster.

Test done also, the -Os does not provide a significative change. Just to show some numbers:

with -Os, all checks (overflow...) iteration time: 3.650 secs. with -Os, all checks + heaptrace iteration time: 3.517 secs.

So, heap trace makes programs faster :-?

The cache theory is fine, but the -O2,-O3 produces smaller code than -O1 (less calls and memory accesses) but program runs slower.

I had also tried to use cmem instead the default memory manager and as expected the results are worst, iteration time 3.870 seconds.

Also gprof is not helping too much because there are no clear differences about calls in both optimized and non optimized modes, except the calls to range check, object check and others as expected in the "with checks" version which runs faster :-?

With gprof I saw in my code a lot of FillChar calls (which are not in my code at all), so I think that they comes from the internal initializations of variables and records, unfortunatly the calls counter does not appear (spontaneous), and the fact that heaptrace produces faster code makes me think in the memory manager, but without a conclusion to this "trivial".