I don't think that an importer-in-chief module is likely to help, and I doubt that smaller versus larger modules will matter much.
Rewriting to avoid a dependency does work, but usually only if you can avoid some large subsystem (such as the contract system) completely. I doubt that `include` will help. If it happens that you're creating a fresh namespace for every compilation, then you can probably decrease compilation time by using a single namespace or by attaching modules to the compilation namespace. My guess is that you're not using separate namespaces, though. Can you provide a small example that illustrates the problem? Seeing a concrete example might trigger ideas that wouldn't come to mind otherwise. At Thu, 20 Feb 2014 19:40:50 -0800, Matthew Butterick wrote: > 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 ____________________ Racket Users list: http://lists.racket-lang.org/users
