On Tuesday, 4 June 2013 at 19:20:26 UTC, H. S. Teoh wrote:
On Tue, Jun 04, 2013 at 08:59:15PM +0200, Idan Arye wrote:
[...]
Due to these characteristics of Phobos, I believe making the
imports
local to the unit tests and templates that use them will
reduce the
number of imports the compiler has to do.
This breaks DRY because some imports are used by multiple
unittests. As
long as the imports are wrapped in version(unittest) blocks, I
don't see
this as a problem.
That's like saying that defining a local `i` variable for using
in a `for` loop breaks DRY, because you could have defined it
once at global scope.
Importing the same module over and over does not break DRY, just
like calling the same function in multiple places does not break
DRY. Breaking DRY means to write the internal code of that
function in several places - or implementing the same things in
several modules.
[...]
Also, I'm not really familiar with the internals of dmd - how
much
impact will importing the same module many times have on the
compilation performance? Will it be more or less than what we
save
by reducing the number of imported modules?
[...]
I may be wrong, but I seem to recall hearing/seeing somewhere
that a
repeated import is just ignored by DMD, since it has already
loaded the
imported module. If not, then DMD should be fixed to do that. :)
I'm pretty sure dmd ignores already loaded modules - if it
didn't, trying to compile anything that uses Phobos would enter
an infinite loop/recursion - and I'm not sure about ignoring
already imported modules, but it probably does that too. Not
doing it would have a major impact on compilation performance,
considering that most Phobos modules import many of the other
modules.
The problem is that ignoring an import, while cheaper than doing
the import and much much much cheaper than loading the module, is
not a free action. Before the compiler decides to ignore an
import, it needs to perform a lookup to check that it was already
imported. If an import is local to a template, this lookup will
be performed every time the template is instantiated - and if the
lookup is not fast enough, this can add up to harm performance.
I believe that lookup is pretty fast, but as I'm not familiar
with the dmd implementation I can't know this for sure, so I
thought it would be better to bring it up.
