Are there any preferred practices in terms of optimizing one's importing technique for the preferences of the Racket compiler? My project involves a lot of real-time recompiling of code (= dynamic evaluation of web templates), so the costs of the initial imports on each recompile have become the gating factor to better performance. Once everything is queued up, the data processing itself is pretty quick.
Sample questions, though maybe they are the wrong ones to ask: Rather than having a many-to-many importing relationship among modules, is it better to designate one module as the importer-in-chief and have it transmit the imports to the other modules, using (provide (all-from-out ...))? Should code be organized in smaller modules (more compiling events, but less code to compile) or larger modules? My impression based on using it is that the greatest expense is firing up the compiler, so more code per module is more efficient. How terrible is it to rewrite code to avoid a dependency? It's always better for performance, but it also defeats the purpose of having modules with common definitions. This surfaces also when breaking a module into submodules. The submodule divisions may make semantic sense, but if the submodules rely on each other, then importing any one submodule drags them all along anyhow. Perhaps one is better off just leaving all the code in one module, unless you can really create independent submodules. Is 'include' a legitimate way to get around this — by writing the code once, but allowing it to be compiled within multiple modules? ____________________ Racket Users list: http://lists.racket-lang.org/users
