On 6/1/18 11:42 AM, Neia Neutuladh wrote:
On Friday, 1 June 2018 at 12:50:31 UTC, Steven Schveighoffer wrote:
A fly in the ointment is .di files. This works today and does the
right thing:
This actually is not a problem, because the dependency tree doesn't
depend on whether the imported module has static ctors. It's how this
works today -- each module only knows whether the modules has static
ctors, and what imports it has. It doesn't go further than that.
Thanks to .di files, when I compile my executable, I don't always know
which modules import which other modules. That was half the point of my
example.
The .di file is just an interface, it doesn't know what's actually
compiled in the binary.
To put it another way, the compiler only generates a ModuleInfo (or
dependency modules) for .d files. .di files are simply a public API for
the .d files.
Are you talking about giving the initialization order for a subset of
modules? Because that wouldn't give much of a speed increase. Or do you
need all of your dependencies to have their own dependency order, and
the compiler can concatenate them?
Speed is one aspect, but the more important aspect is to do more
fine-grained dependency tracking. Doing it on a function level vs.
simply assuming all things in the module depend on all things in the
dependent modules, allowing for instance module cycles where there is no
real cycle between the data initialized. That's not going to work well
with today's mechanisms because it would be much more expensive both in
runtime and memory usage, and even further highlight the drawback that
we are solving the same static problem on every run of a program.
As an alternative, you could produce the initialization order by running
the program and seeing what order it uses.
Yes, but this still involves pushing all the dependency data into the
binary. All we should care about at runtime is the order to execute
ctors. We could even eliminate the needless storage of all the
dependency modules that is there now.
-Steve
