This sounds more like a research program than a 'dev' question :-)
On Feb 20, 2014, at 10:40 PM, Matthew Butterick <[email protected]> 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
