Memory and Performance

Does DrScheme really require at least 32 MB of memory?

Yes.

Why does DrScheme require so much memory?

DrScheme is large and complex program in ways that are not immediately apparent. DrScheme's editor is a multimedia editor that handles pictures and embedded editors. DrScheme is multi-threaded (many things happen at once) so that executing a program does not interfere with the development environment. These vital features contribute in various ways to DrScheme's overall memory use. Finally, DrScheme is itself implemented as a large Scheme program, and the compiled instructions for executing DrScheme consume considerable space.

All things considered, DrScheme still uses somewhat more memory than it might. The reason is that PLT has traded some memory efficiency for faster devlopment of DrScheme. MzScheme, DrScheme's underlying Scheme implementation (which is also used to implement DrScheme), employs a form of memory management (a form of ``garbage collection'') that is not very precise, but that makes it easier to implement MzScheme's built-in features and the GUI toolbox. As a result, DrScheme consumes more memory than it would otherwise, but the result of this trade-off is a higher-quality environment in many other respects.

DrScheme works fine at first, but then starts using more and more memory. Is there a ``memory leak'' in DrScheme?

DrScheme will eventually stop consuming memory, although the stabilization point may be quite high. If DrScheme increases its memory use even when you are not using DrScheme, please submit a bug report.

Why does analyzing a program with MrSpidey use even more memory?

MrSpidey is a large program, and it needs a very large working memory to calculate the flow of values in a program.

Why does DrScheme take so long to start up?

DrScheme is implemented in MzScheme, and our current technology does not provide a mechanism to compile Scheme code into a block-readable form that is immediately easy to execute. Instead, many files have to be loaded and the code implementing DrScheme is extracted from these files.

Why is DrScheme so slow at parsing large programs (even compared to PLT's own MzScheme)?

Unlike MzScheme, DrScheme maintains source location information as it parses programs. This information is used to highlight program text for syntax and run-time errors. Partly, the source-correlating parser and compiler is slower than a typical Scheme parser and compiler (such as MzScheme's) because it works harder to maintain location information. Partly, it's slower because DrScheme is implemented as a MzScheme program; MzScheme's parser and compiler are considerably simpler, and can therefore be implemented in a low-level language that executes ten times faster than Scheme programs with our current technology. We are working on Scheme compiler technology that will narrow this gap and speed up DrScheme's parser.

Why do programs run more slowly in DrScheme than in other Scheme implementations (including PLT's own MzScheme)?

Programs run more slowly in DrScheme because DrScheme inserts extra checks into a program to provide information about the location of run-time errors. Turning off the ``Signal undefined variables when first referenced'' language option in DrScheme can speed up programs significantly.