One of the cardinal sins of a program is to be slow. Here I am not talking about sluggishness caused by a poorly optimized algorithm, but the kinds of delays caused by the language and frameworks that are somewhat beyond the programmer’s control. Languages such as Java and Lisp are often criticized by opponents as being naturally slow languages, but what such criticisms miss is that languages can be slow in four different ways, and not all of them are equally sinful, and what matters to a business application in terms of speed is different from what matters in a real time game. The four basic categories are as follows:
Universal slowness is the kind we most often associate with interpreted languages. Such a slowdown is caused because every operation has a slight overhead, and thus all parts of the program will be slowed in comparison to its native counterpart. Some see universal slowness as the most damning kind, but in reality it is the least significant, partly because it is the easiest to code around. If your program is running too slow because of the language it is written in the solution is simple, write the most computationally expensive routines in a faster language as libraries or extensions. In fact many programs could even be reduced in speed without the user noticing at all, as long as they were still able to keep up with user input.
Periodic slowness is most often caused by garbage collection, but it could be also caused by a program having to wait on a slow network connection or having to process a batch of disk operations. Periodic slowness is usually only a problem in real-time applications, normally games, and in applications that expect a steady stream of user input. In such a program the user will experience occasional “lag”. Unfortunately there is no way to completely eliminate the cost of garbage collection. It is true that garbage collectors could be written that operated constantly and thus took an even toll on program performance, but these are much harder to write, and hence much rarer. Although there are coding techniques to reduce the time your garbage collector will take to run in some ways it is out of your hands.
Start-up slowness is often caused when either a large run-time framework must be loaded for the program, for example Java, or when complex initialization of data or graphics must be done. The splash screens associated with some programs such a word, open office, ect are signs of this problem. The cost of start-up slowness is completely dependant on how the program is used. If the program is typically used for long periods of time then the start-up slowness is of little cost to the user, as they expect to be devoting a lot of time to using the program anyways. However if the program is designed to be a simple gadget, or something used only briefly, then start-up time is a large annoyance to the user.
A program can be slow to respond to user input either when it is busy with some other task, or when the framework it uses to manage the user interface is exceedingly cumbersome. Interactivity slowness is the most damning way a program can be slow, because it makes the program difficult for the user to work with. Some programs which suffer from this problem can be fixed simply by putting the user interface in its own dedicated thread. However in web applications, which may be slow to respond due to network delays, a fix to this kind of slowness may require a new way of approaching the problem.
Lets examine Dr. Scheme in these terms. Dr. Scheme has a long startup time, but since you will generally be coding for a while this is mostly irrelevant. Although Dr. Scheme incorporates Scheme, and thus the garbage collector is running, it never seems to interfere with its ability to keep up with user input. Most importantly Dr. Scheme responds to mouse clicks and typing without delay, which makes it feel like a fast program.
We can compare this to a small 2D game written in Scheme (I have been working on one). When compiled the program starts quickly, runs quickly, and responds well to the user. However it does suffer noticeably from garbage collection (occasional jerkiness). Although this is probably acceptable for a small little game it might not be for a big budget endeavor.