Prior to v4.1.5.4 (which is now the SVN trunk), then scheme -l program
would not only execute the run-time code for `program', it would also run all the compile-time code, and the compile-compile-time code, and so on --- just in case you later evaluate an expression that requires macro expansion in the module's namespace. In v4.1.5.4, phases above 0 are evaluated on-demand when some expansion is initiated at the prior phase. In the above example, if `program' doesn't call functions like `eval', then code at phase 0 and higher will not run. Even if `program' calls `eval', if the evaluated expressions never include phase-1 code (such as the right-hand side of a `define-syntax' or `let-values'), then phase 2 is never run, and so on. For some programs, this change saves start-up time. For example, just mzscheme -l scheme or mzscheme -l scheme -e '(exit)' is about 40% faster than in v4.1.5. Previously, the above command-line had to start a tower of modules that was about 18 phases deep, while only 1-2 phases are now run. (The difference between the above examples is in whether phase 1 has to run to compile `(exit)'.) In principle, the savings from on-demand instantiation can be substantial. In practice, the savings are modest, such as twice-as-fast no-op examples as above, a 2-4% reduction in DrScheme's initial footprint, and slightly faster loading of Scribble documents like "reference.scrbl" that use many sandboxes for examples. None of these savings are big, because instantiating a module that is use `for-syntax' usually doesn't cost much, but the savings seem enough to be worthwhile. There's some risk on-demand lazy instantiation of phases will be confusing --- mostly if you try to use printouts to track what's going on. Again, this looks (so far) like a good trade-off for better performance. Most importantly, on-demand instantiation is at the phase granularity, not module granularity; there are no new ordering issues within a phase, and the intentional difficulty of sharing across a phase should minimize ordering effects across phases. _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
