"I made a game using Rust"

[Marco Leise via Digitalmars-d]

Am Fri, 12 May 2017 05:42:58 +0000
schrieb Lewis <musicaljelly at 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