XE Update 1: you win some, you lose some
In my first look at Delphi XE, I wrote:
Oh, and apparently certain aspects of the compiler have slowed down. Most things will compile about the same speed or even a little faster, but for really large projects (millions of lines) with complex interdependencies between units, you’ll notice some slowdown, and it’ll apparently get worse the larger your project is. I timed it at work, on a project of about 3.5 million lines of code. It builds in about 2 minutes on D2010, closer to 3 minutes on XE. Bad, but still a heck of a lot better than the C family could do. And apparently it has something to do with making Generics work right, so I can tolerate that. Hopefully they’ll find some way to regain some of that lost speed in updates, though.
Well, I finally got around to installing XE Update 1 at work today, and I timed the build. 2:13.
Unfortunately, one of my coworkers stumbled across a nasty new edge case that didn’t exist in XE RTM. If you open a very large project, (the one at work is millions of lines of code, with thousands of units used in the DPR,) pull up the DPR, and do something that produces an error dialog, such as trying to Find an invalid text snippet, before compiling, the IDE locks up on you, burning one core at 100% until you kill it.
I opened a second instance of Delphi and attached the debugger and got some interesting results. I don’t have Andreas Hausladen’s IDE-spelunking brilliance, but apparently the main thread is waiting on something to finish, and if I had to guess, I’d say that it’s running a background compile to build *Insight tables.
I submitted a QC report on this, but something went wrong somewhere and it’s not publicly viewable. I put a comment on the report to that effect; hopefully someone at Emb. will change it. So if you can see QC# 90020, feel free to vote for it.
So Congrats to Barry and the compiler team for getting the compile time back down on par with D2010, and a big raspberry to whoever introduced yet another bit of behavior that blocks the main thread for a perceptible length of time. That’s something that should never happen. It’s gotten better recently, but it still happens far too often in the IDE. Hopefully the next update will fix this issue.
QC report #90020 is unavalable:
Either there is no report #90020, or you are not authorized to see that report.
BTW: if a thread really waits (ex WaitForSingleObject) it does not load CPU.
Correction: If a thread waits USING A SIGNALED WAIT OPERATION then it SHOULD NOT load the CPU.
But a thread can wait for something to complete in a myriad of ways, some of which absolutely will load a CPU.
It may be using a signaled wait with a VERY short timeout (1ms timeout waiting on a mutex and continually retrying when it times out), or it may naively be busy-waiting, polling some memory location for an indicator.
I wouldn’t say it’s a common mistake, but it is a mistake I have seen people make, to think : I should only wait for the shortest possible time so that my code will respond as quickly as possible once the thing I am waiting for is ready.
Of course, one would hope that no-one would be so dumb as to use a busy wait in a way that could lead to a process hang, but such hopes have a nasty habit of being dashed …
What it looks like is that the main thread is waiting using a signaled wait, which doesn’t consume any CPU, to wait on something else which does, such as the compiler.
Have you tried with Andreas Hausladen’s IDEFixPack 4.0 (beta) to see if it makes it better? (http://andy.jgknet.de/blog/2010/11/the-idefixpack-4-0-beta-begins/)
I don’t have that monster of a project anymore, so I could not test… 😉
Excuse me for asking such a foolish question but: what kind of application has mil. of line of code(except for the ones that you use to test compiler speed…)?! 😛
I mean, doesn’t it make more sense to break it into multiple smaller applications(modules, plugins if you will)?!
P.S. Please don’t get offended in any way, I’m very curious that’s all. 😀
An “enterprise” app that does basically anything and everything that any client has needed over the last ten years or so. And yeah, it would probably make more sense to break it into modules, but that’s much easier to do when you start out designing it that way than later on, once the need for it becomes apparent.
Thankfully we have a fast compiler that can handle that kind of load. Can you imagine trying to build 3.5 MLOC in C++? It would be churning for hours!
Frankly I don’t even want to imagine doing it in C++, I also received a pretty big project with lots and lots and lots 😛 of features BUT from the beginning I’ve put my foot in front and said: “we’re going to break it into multiple smaller applications for speed of development and if at any time we need more work power, you can add another developer and assign just one application in stead of *parts* from the application…” — I’m really happy I convinced them.
However in your case it’s harder, over 10 years means a lot of developers worked on it and there are lots of different coding styles used, correct?
@Dorin, you are correct (unfortunately for Mason :-p)
The ‘private’ flag got fixed.
QC 90020 is there now: http://qc.embarcadero.com/wc/qcmain.aspx?d=90020
Just voted 🙂
–jeroen
Thanks for the info. Just voted!
I’m glad to know there are projects too large on Delphi and you can compile them.
I had this problem too! But I hadn’t looked for the real problem. I think that it has something to do with the search and compilation but nothing exactly. When you work in smaller projects this is really nerving… So I changed back to D2010. I don’t want to have to kill bds.exe every 20 minutes!
Perhaps you have the same problem: I cannot view the welcome page?
I guess that a Delphi IDE free of bugs is just a dream.
Still have bad dreams with Delphi 2005.
And that’s why I will stay using Delphi 2010 even with all the bugs it has.
I also have a huge project that is my everyday project, and I can’t count the times I have to kill bds.exe, because it just crashes when it goes over 1.2gb of ram used.
It seems that Embarcadero needs to check Delphi’s quality control if it wants to avoid users from flying away to VS.
I already use VS for new projects, and even with any problem that VS might have, the productivity is much better than with Delphi.
I am a Borland user since Turbo Pascal 3, and its very sad to see Delphi like this.