In comment of Jim McKeeth 's "How big is your Delphi project?" (http://community.embarcadero.com/blogs?view=entry&id=8890 which does not allow comments).
In comment of Jim McKeeth 's "How big is your Delphi project?" (http://community.embarcadero.com/blogs?view=entry&id=8890 which does not allow comments).
Largest binary here is 1.57 millions lines, full build in about 15 seconds, with optimizations and detailed map file (without map file, build takes 12 seconds). This is with XE 32bits.
...and this is with an "old" AMD Phenom II CPU. Compile times are definitely one of the reasons I keep using Delphi.
Hopefully compiler speed will be a renewed focus for future Delphi versions!
Win32 compilerspeed was never an issue - yes, performance (especially with many generics involved) went downhill a bit but greatly improved in Berlin again.
ReplyDeleteHowever what I am still worried about is nextgen compiletime - I mean, that thing is sloooow (http://xkcd.com/303/) - not sure though if that is just LLVM to blame or if there are some issues to look for in the frontend.
Compiling one MLOC with the Win32 compiler in five seconds is totally unrealistic. That maybe works with IDE Fix Pack, an OC Skylake CPU and a non real life project generated for that synthetic benchmark with a lot empty lines.
ReplyDeleteFor a 1.99 MLOC real life project that uses Generics moderately for lists in Debug Mode with detailed MAP file on a 3rd generation i5 at 2.8 GHz and an SSD compilation takes 22 seconds with IDE Fix Pack and 42 seconds without IDE Fix Pack.
A real benchmark would compile at least a dozen OS Delphi projects and list for each the revision.
Uwe Schuster Last time (like 1 minute ago ^^) I checked Berlin Win32 with and without IDEFixPack 5.95 was almost the same speed for the Spring4D project group.
ReplyDeleteUwe Schuster yes, forgot to mention my timings are with the IDE Fix Pack and an SSD.
ReplyDeleteI have a smaller project with 778k lines that compiles in 3.9 seconds (without map file), which is more or less in line with 5 sec for 1 MLOC, but that is for Delphi XE.
XE2 Win32 is around 10% slower on the same projects (with fix pack), and Berlin Win32 is 50% slower (without fix pack) or 10% slower (with fix pack).
(btw i5 3rd gen at 2.8GHz, isn't that one of those dual-core, smaller CPU cache low-power laptop i5?)
The sample code I used did not have generics and did not have the IDE FixPack. I'm going to make another test with Generics to show the speed improvements of Berlin over Seattle.
ReplyDeleteI have a 500k lines project and it builds in "just" 9 minutes for iOS Device target ;-)
ReplyDeleteBeing inspired I gave our 8 MLOC C++ application a test compile in 10.1.1 to compare with bcc32 it took 1min 36.4 sec so not bad. I then spent lets say 3-4 hours adjusting the code to run on the new bcc32c Clang compiler to see how that performed. I managed an EYE WATERING 3 min and 43.2 secs and actually never completed as the linker needed some obscure lib I'm still trying to work out why. Roughly that was on EVERY ERROR FIX and compile ! Was close to smashing something.
ReplyDeleteActually, I have had another crack, maybe a sucker for punishment. Took a bit to get the bcc32c to compile and link correctly.
ReplyDeletebcc32 was 1 min 42.8 seconds and drum roll........brrrrrhhhh bcc32c 11 minutes and 2.4 seconds......we have a new winner! ;-) yes those are tears.
ok, I have this working better now. 8.3 MLOC compiled in 28.6 seconds using parallel compilation on a i7 3930k with SSD. My Macbook Pro is down to 2 min 27 seconds. Much happier.
ReplyDelete