Fast Development

I recall a Microsoft magazine ad from the mid-1980’s, back when Microsoft was best known for the compiler. The ad was four pages long. The first page said that their new development environment had the three things every programmer wanted. I didn’t use Microsoft tools in any case, but when I looked at that page, I immediately thought “I only want one thing from my development environment: I want it to be faster.” The “three things” were on the next three pages of the ad: they were speed (of compiling the program), speed (of debugging the program), and speed (of the generated code). That was an ad writer who really understood what programmers want.

I’m a long-time emacs user and I’ve never used a more integrated development environment. I played around with Eclipse a few years back and at the time it was slow. In emacs I turn off font-lock mode because it is slow. When it comes to writing code I want to be able to just write.

Of course Eclipse, and font-lock mode, bring another advantage: they make it more likely for your code to be correct as you write it, since they can point out typos right away. I typically don’t find typos until I compile the code. So I definitely see an advantage to using an editor which parses your code as you type–as long as you never have to wait for it.

Speed of compilation is still an issue, at least with C/C++. Using a compilation cluster is easy with distcc, as long as you have a few machines to run compiles on. You’re still limited by how long it takes the largest piece of your program to compile, which can easily be 30 seconds. And of course the link time is serialized, although I have ideas on how to speed that up. The ideal compilation time should be no more than a few seconds–short enough that you don’t switch onto another task. I have not used Eclipse for Java development, but I gather that compilation can be very fast. I hope that Tom Tromey’s work on incremental compilation can help with C/C++.

I don’t personally find that speed of debugging is much of an issue for me these days. The debugger is not the first tool I reach for to find problems in code, and when I do, I normally find that gdb is fast enough.

Speed of development is one of the big advantages of the interpreted languages like Python. There have been interpreted environments for C/C++ in the past, trying to provide the same development time benefits while still permitting fast execution. None of them have caught on, and these days a development environment will only catch on if it is near zero-cost. I’ve never used one, so I don’t know what it is like.

In any case, I still fully agree with that old Microsoft ad: the only way to judge a development environment is by how fast it lets you write code, by how fast you can debug the code, and by how fast the program runs. Any bells and whistles which aren’t directly related to making things faster are irrelevant.


  1. tromey said,

    June 11, 2008 @ 8:49 am

    >> In emacs I turn off font-lock mode because it is slow.


    If you like font-lock at all, you might want to try again.
    Recent versions of Emacs do JIT font-locking.
    The old pauses are basically gone.

    My ideal recompile time is “faster than I can notice”.
    I don’t think we can achieve that, at least not with gcc and the realities of C and C++.

  2. jldugger said,

    June 11, 2008 @ 2:06 pm

    I don’t spend a lot of time writing a single piece of software, rather I tend to flit from program to program to fix bugs etc. I prefer emacs as a text editor, mostly because I’m slightly familiar with it.

    Eclipse JDT is fantastic, really. I used it in my compiler design class, and it’s got some compelling arguments. There’s an integrated tutorial showing you how to start a new project with JDT. It tells you what to do and recognizes when you’ve done it. do not underestimate the value of a steep learning curve. Its autocomplete also is well done and is handy for debugging complicated exceptions. I also found JUnit handy when writing a parser in ANTLR. With 80 or so test cases, you can do a pretty good job exercising the grammar (at least a simple one) and get a good idea of how much progress you’re making.

    Eclipse CDT however, is not your guy.

    Speed of writing is why I don’t use Eclipse. CDT is terribly slow still on autocomplete, which triggers by default on several annoying conditions. I’ve found no

    Many students ask me about visual debuggers on UNIX, and many end up using DDD. I’ve been meaning to learn more about the eclipse debugger in CDT, but the CDT is so bad I can’t bear to write any code to debug in it.

  3. ncm said,

    June 11, 2008 @ 2:06 pm

    Sorry, doesn’t fly. A huge fraction of the instructions executed in Gcc are concerned not with making the program run faster, but with ensuring that both the source code you wrote, and the object code it emits, are correct. Of course those instructions make the compiler itself slower, and thank goodness for them. A faster compiler that welcomes or emits bad code, and a faster program that produces wrong results, would both be much, much easier to write than what we do choose to spend our time on.

    What you’re really talking about is minimizing the final cost of software, which is what we make tools for in the first place. The more things they do faster than we can, the better off we are.

    Tom: The next C++ (i.e. after C++0x) may well have a proper module system, and be better-suited for incremental compilation.

  4. Ian Lance Taylor said,

    June 11, 2008 @ 5:09 pm

    During the development cycle, there is no need for optimized code, so it should be possible to compile much faster than gcc does today. And checking for dubious constructs doesn’t have to be part of the compilation process proper, it can be done separately. So I think we really can make things faster. As jldugger says, look at what Eclipse can do with Java.

    I’m not sure what a C++ module system would look like, but anything which saves us from reading and parsing tens of thousands of lines of header files would help a lot.

RSS feed for comments on this post · TrackBack URI

You must be logged in to post a comment.