On 5/19/16 11:56 AM, Georgi D wrote:
On Thursday, 19 May 2016 at 12:38:09 UTC, Steven Schveighoffer wrote:
On 5/17/16 6:04 PM, ZombineDev wrote:
I'm guessing that is highly related to this one:
https://issues.dlang.org/show_bug.cgi?id=15831
Yep. chain uses voldemort type, map does not.
Georgi: try copying chain implementation into your local file, but
instead of having a static internal struct, move it to a module-level
struct (you probably have to repeat the template parameters, but not
the constraints). See if it produces a similar slimming effect.
Yes,
Making a local copy of chain and moving the structure outside of the
method solved the problem and reduced the code size.
Thanks, that confirms the bug reports are for the same issue.
The stripped size even reduced from the version that did not experience
the huge increase. Stripped: 7.4Mb -> 5.5MB
Should we actually change the implementation in phobos to be like this?
I'd much prefer we fix the compiler to handle voldemort types in a more
sane way rather than try and fix the code to deal with compiler
deficiencies. However, if this isn't something that's easily done (or
done within a decent time frame), we may look at that solution.
In the company I work in we are very sensitive to the code size so
anything that can be made for this in phobos will help with adoption.
I am still curious though why the code size increased so dramatically
with such a small change. Both versions return a result from chain and
actually the one that does not experience the increase is more complex
(includes the one that does).
Each call to a voldemort wrapping function (one that wraps one type into
another "voldemort" type, or internal struct) increases the symbol size
at a rate of 3^n. Non-voldemort types do not suffer from this, because
the symbol size increases at just n.
In my actual code I have multiple calls to chain on top of the result of
this and the code size does not increase dramatically.
I am also concerned by the fact that ldc on mac just could not compile
the source which produced the big binary (entering an infinite loop).
I would expect the possibility that the issue is with the linker. In my
toy experiments, the compiler works just fine and produces an object
file. It's the linker having issues with parsing those humungous symbols.
-Steve
