Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

For a reason that is largely irrelevant, I installed Delphi 7 once again in such a long time. I have to say, I was completely blown away - in a way I haven't been for rather a while. This is not how I remember things at all. The installation took around 30 seconds. Launching it took 2 seconds, and it was immediately usable. I can press "Run" the second after it started, and less than a second later the blank program is already visible and running. Hurray for computers getting so much faster!

But the reason I've been blown away like this is because usually I use Visual Studio 2010, that doesn't feel snappy like this at all. Granted, Delphi 7 is a much smaller system than Visual Studio 2010, but it does have the appearance of having all the really necessary things there: a control palette, a form designer, a code editor with code completion. I realise that the language might be simpler, and the code completion might be a lot less powerful, and the IDE might not be nearly as extensible and feature-rich, but still: I do not understand how (i.e. through what mechanism) does having a lot of extra features (that I might not have even triggered yet) cause a system like Visual Studio to always feel sluggish in comparison.

I would like to ask people experienced in working with systems the scale of Visual Studio: what is it that makes them slow? Is it the layers upon layers of abstractions required to keep the codebase within the human comprehension capabilities? Is it the sheer amount of code that needs to be run through? Is it the modern tendency towards programmer-time-saving approaches at the (mindbogglingly huge) expense in the clock cycles / memory usage department?

share|improve this question
Simple: as mass increases, more force is required to overcome inertia. – Shog9 Jan 22 '11 at 3:57
Someone once told me managers but I don't believe that at all. – MIchael Grassman Jan 22 '11 at 4:16
This is a large part of the reason I still primarily use D7 for Delphi programming. – GrandmasterB Jan 22 '11 at 6:31
The fastest code is that which never gets executed. – Henry Jan 24 '11 at 0:06
@romkyns: I find much software in the modern era is often incredibly bloated, unnecessarily large and unwieldy. A lot of the software now solves the same issues that were solved ten, even twenty years ago, with a fraction of the power and space. Why does it still lag as badly as it ever did, if not more so? Inefficiency and bloat. – Orbling Jan 24 '11 at 0:48

2 Answers 2

up vote 14 down vote accepted

Architectural Astronautics

Visual Studio 2010 is built upon Windows Presentation Foundation. Take a look at the Button class for WPF. It is the 9th child of a base class. It has around 5 pages of properties, methods, and events. Behind the scenes it has another five pages of style definitions that describe its beautifully rounded corners and the subtle animation transitions when a mouse cursor moves over it. This is all for something that fundamentally displays some text or a picture and produces a click event when it detects a mouse button going down.

Stop a program like Visual Studio at any random point. Look at the stack trace. Chances are very good that you're 20 levels deep into the calling stack and that five DLLs were loaded to get there.

Now, compare these two things with Delphi. I bet you find that a Delphi Button has just 20 properties, methods, and events. I bet the Delphi IDE only has a stack trace 5-7 levels deep. Because when computers were slower, you just couldn't take the overhead of Visual Studio 2010 without the IDE taking 40 minutes to start :-)

Is one better than the other? Well, I can generally tell a Delphi program when it loads because it looks flat, the colors are muted (8 bit perhaps?), and there's no subtle shading or animation. I just feels 'cheap' these days. Cheap, but fast.

Are we better off? That's a question for the philosophers, not the coders.

share|improve this answer
A delphi program doesnt look flat. Rather, a programmer programs a program to look flat. You can make nice looking, modern, full color interfaces with Delphi just as you could in C# or C++. – GrandmasterB Jan 22 '11 at 6:35
This is an insightful answer; but I’m not sure it is complete. Visual Studio 2008 (the predecessor of 2010) has no WPF in it and is still worlds slower than Delphi 7. Would you still say the same thing about the call stack depth and the number of DLLs loaded? – Timwi Jan 22 '11 at 14:14
@Timwi Yes, absolutely I would. My point was less about the evils of WPF (I like WPF actually) and more about how we tend to add layers upon layers of software abstraction when given the choice. Perhaps Visual Studio 2008 didn't have quite as much overhead, but as you noted it had quite enough :-) – Jay Beavers Jan 22 '11 at 21:10
@GrandmasterB, I'm not slamming Delphi because it comes with fewer assumptions and simpler libraries. WPF was designed assuming GPU hardware acceleration would allow programs to use deeper colors, frequent animations, alpha blending, shadows, etc. Delphi was engineered at a time when these assumptions could not be made. Could you re-implement this all in Delphi? Sure, but you'd have to put a lot of coding in just to get the behavior of a WPF button. On the plus side, a Delphi button doesn't come with CPU, memory, and GPU requirements a WPF button has either which was the @OP's question. – Jay Beavers Jan 22 '11 at 21:13

You've basically got it. High levels of abstraction carry inevitable performance pentalties, and large codebases tend to be rather hard on the CPU cache, slowing things down further.

Plus, one other thing to remember. Visual Studio comes from Microsoft. That automatically imposes a sizable performance penalty by default. ;)

share|improve this answer
-1 for the unconstructive polemic. – Timwi Jan 22 '11 at 14:11
+1 For accurate analysis. – Orbling Jan 24 '11 at 0:13
This site runs on Microsoft products and its pretty damn quick. – JeffO May 4 '11 at 0:15
-1 for prejudice. – user1249 Jun 19 '11 at 14:59
-1 - Q:"What makes large, complex software slow?"; A:"Large complex software tends to be slow." – Morgan Herlocker Oct 12 '11 at 18:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.