Am Fri, 12 May 2017 05:42:58 +0000 schrieb Lewis <musicalje...@gmail.com>:
> Ah okay. If I understand correctly, the "game" itself is just the > two .d files in the Scripts folder, which get compiled then > linked with the prebuilt .lib for the engine. If so, a 10-12s > compile just for those two files still sounds really long to me. > Either I'm misunderstanding, or there's something bizarre going > on that's causing those build times. You can't tell how long a compile takes from looking at the size of the modules you pass to the linker. Unlike C++, Dlang lacks header files that could short-circuit import chains. What this means is that all the imports in a module (except inside templates) are analyzed recursively. In the game at hand this only means parsing the entire engine code base in addition to the two modules, but projected onto LibreOffice or other big projects it would parse the code of so many libraries that compilation times would sky-rocket. (I told this story here once or twice before, but haven't actively done anything to improve the situation.) Things you can do today: - If an import is only used in templates, copy it inside of them. This works today and stops the import from being analyzed unless the template is instantiated during the compilation. Multiple instances wont pessimize compile times. - Move imports from top-level into the functions that use them. There is no other way to say "This import not needed by our public interface". - Don't turn everything and the dog into a template. Nested templates stretching over several modules require analysis of all those modules along the way, while a regular function may stop right there. - Following all the above, generate .di files for your library's exported modules. All the imports inside non-template functions will be removed and only what's needed by the public interface (i.e. argument types and return types) is kept. Several ideas spread in the past. From the top of my head: - Walter had the idea to make imports evaluate lazily, and improve the situation without resorting to .di files. - Some issued with the .di file generation stop it from being widely used for example by dub when installing libraries. - The "export" keyword could be narrowed down to be the only visibility level that goes into the .di files created for a library. (Removing public and package visibility symbols and imports pulled in by them in turn.) Last not least, with single-file-compilation like in C++ you may still shoot yourself in the foot in Dlang, because when you update a template and forget to recompile all modules that instantiate it, it is left in the old state there and cause conflicts at link time or runtime errors. Disclaimer: If you find mistakes in the above or something simply isn't true any more please give an update on the current situation. -- Marco