Hello,

I have spent some time to profile the compiler using callgrind, and was able to improve its speed by about 20%. Attached are the changes that I made to the sources.

Some comments:
daopt386.pas: original code was calling fpc_varset_load (twice), fpc_varset_create_element and fpc_varset_add - all for just setting a single bit! I wonder if that can be done slower at all :)

ppu.pas: probably the commented out block must be appropriately $ifdef'ed. But at least on i586 System.Move is optimized so well that always calling it makes tppufile.readdata about twice faster.

fppu.pas: The design of compiler messaging (load and format messages _before_ checking verbosity level) is good for errors and warnings, but is a waste of time for reporting several thousands tried and used units. Therefore I added verbosity checks before any attempts to output something.

cfileutils.pas: Rewrote FixPath() and FindFile() to exclude implicit AnsiString temp vars and so on.

cmsgs.pas: used ShortString version of StrPas() to avoid conversions.

I hope that at least some of this patching can be used in mainstream :)

Best regards,
Sergei

I gave the patch a quick try and the speed stays the same for compiling the compiler sources. Can you explain how you did measure the performance gain?

Peter

Sounds goodl! Was it an overall improvement? What 'benchmark' was '20% faster' with the patches? Guess it was compiling the compiler?

Regards John

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

Peter Vreman wrote

I gave the patch a quick try and the speed stays the same for compiling the compiler sources. Can you explain how you did measure the performance gain?

First, I compiled the compiler using -gl switch in order to have procedure names in logs.
Then I compiled a project (it was my working copy of packages/fcl-xml/tests/xmlts.pp) using callgrind:

valgrind --tool=callgrind ppc386 -S2h -dRELEASE -gl xmlts.pp

Finally, annotated the log:

callgrind_annotate --tree=calling >file.txt

As a result, you get a file with call tree and execution times for most procedures. The numbers are very consistent across multiple runs. I observed decrease in "Program totals" number (I actually don't know what it is - CPU instructions, ticks or something arbitrary): from 410,867,243 to 302,717,628.

I suspect that these numbers do not include time spent by kernel in disk i/o procedures, and that kernel time may be so high that it masks out all improvements. Also, I compiled a program with all used units already compiled, so in my case .ppu creation was not covered. But anyway, smaller numbers should be better than bigger ones.

Sergei

The changes seem to be logical to me though :)

Below are the number that i get when i compiled fppkg from r9259. These show only 3% improvement. But also small bits help and i'll apply the patches after some cleanups.

Old compile all units:

==4852== I refs: 1,649,289,307

Old PPU Load:

==4862== I refs: 513,954,604

New compile all units:

==4280== I refs: 1,634,900,650

New PPU load:

==4290== I refs: 496,248,276

Peter

Peter Vreman wrote

Below are the number that i get when i compiled fppkg from r9259. These show only 3% improvement. But also small bits help and i'll apply the patches after some cleanups.

Looks like I was too optimistic in my first estimation :) Still, testing the fppkg project (commandline: "ppc386 fppkg.pp -Fulnet -FUunits/i386-linux") gives me approximately the same ratios as I initially got for xmlts:

Patched Unpatched
No smartlink
Build all 1,338,810,161 1,670,449,515
Load PPU 386,845,718 596,421,046

With smartlink
Build all 1,646,774,139 2,002,569,727
Load PPU 399,144,263 609,837,470

I guess these numbers are hardware-dependent in some way, so someone else may expect yet another values.
I'll try to do more research on this, and provide more 'small bits'... :)

Sergei