Bug 14680 – Investigate the use of .di files for Phobos

Status
RESOLVED
Resolution
WONTFIX
Severity
enhancement
Priority
P1
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2015-06-11T00:49:22Z
Last change time
2018-02-10T00:12:10Z
Assigned to
No Owner
Creator
Andrei Alexandrescu
Depends on
14687, 14689, 14690, 14694, 14688, 14693

Comments

Comment #0 by andrei — 2015-06-11T00:49:22Z
Using .di files has been attempted last time many years ago for Phobos and showed no improvements in compile times. Back then Phobos was much smaller and .di generation much less reliable than today. We should investigate now whether distributing Phobos importables as .di files instead of .d files would be beneficial. Now we have pragma(inline) which allows us to place in the .di files the functions we want to always inline, or to make available for CTFE. Among the advantages of .di files - they'd be devoid of unittests and comments, which tend to be massive in Phobos,
Comment #1 by andrei — 2015-06-12T04:50:56Z
I made a brief first pass, with encouraging results. The build speed for this program decreased from 0.172s to 0.149s: import std.stdio, std.algorithm, std.range; void main(string[] args) { } That includes linking. Difference in compilation alone is quite a bit higher (2x from 0.07 to 0.036) but of course it's expected that these margins will degrade once semantic analysis starts to dominate. Sadly I was unable to actually call any function because the generated .di files have a number of issues, which I'll file separately. Files in std/*.d have a total of 8,564,957 bytes, whereas the .di generated files have 2,922,494 bytes. On the face of it it makes a lot of sense to not distribute for importing the source files with all comments, unittests etc. in them. So I think we should pursue this.
Comment #2 by schveiguy — 2015-06-12T04:58:31Z
one thing to consider: Your error messages will go into the comment-less no-doc versions, requiring you to go open the manual, or map the code back to the original source if you don't see immediately what is happening in the source. I don't know if it's a bad thing to require people to use the html docs, but I know it's not going to go over well with some people. I'd say our doc generation has to be really good in order to go this route. Even with great HTML documentation, the inline comments may be invaluable when reading the code that has failed. The lack of unit tests would be awesome though. It would solve other problems too -- such as the accidental building of unit tests from phobos templates in user code.
Comment #3 by andrei — 2015-06-12T05:02:39Z
(In reply to Steven Schveighoffer from comment #2) > one thing to consider: Your error messages will go into the comment-less > no-doc versions, requiring you to go open the manual, or map the code back > to the original source if you don't see immediately what is happening in the > source. See also https://issues.dlang.org/show_bug.cgi?id=14689
Comment #4 by greensunny12 — 2018-02-09T20:28:36Z
Tried it here: https://github.com/dlang/phobos/pull/6123 tl;dr: it's not worth it and brings a lot of troubles with it. We simple should make the imports faster. I'm incled to close this as WONTFIX as the investigation is over. OTOH just stripping out the unittest would result in a small improvement - though probably not measurable in comparison to other, more worthwhile tricks at the compiler-level.
Comment #5 by andrei — 2018-02-10T00:12:10Z
Yah, also a bunch of functions won't be available for CTFE.