[racket] how to improve performance by streamlining imports?

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