On 11/14/13 11:43 PM, Gregory Szorc wrote:
> * Why does lots of js/'s source code gravitate towards the "bad"
> extreme for most of the metrics (code size, compiler time,
> preprocessor size)?
We use templates very heavily and we inline like mad.
Templates make C++ compilers go slowly. The GC smart pointer classes are
all templates. They are used everywhere. This will not change.
On to inlines.
"-inl.h" and "inlines.h" headers in mozilla-central
(js/src has more than everything else put together):
https://gist.github.com/jorendorff/7484945
Inlining a function in C++ often requires moving something else, like a
class definition the inline function requiers, into a header too. So the
affordances of C++ are such that unless you pay extremely close
attention to code organization when writing inline-heavy code, you make
a huge mess.
We have made a huge mess.
I don't yet know how to tidy up this kind of mess. I'd love to adopt C++
style rules that would help, but I don't know what those would be.
Nicholas Nethercote and I have spent time fighting this fire:
Bug 872416 -js/src #includes are completely out of control
https://bugzilla.mozilla.org/show_bug.cgi?id=872416
Bug 879831 - js/src #includes are still out of control
https://bugzilla.mozilla.org/show_bug.cgi?id=879831
Bug 886205 - Slim down inlines.h/-inl.h files
https://bugzilla.mozilla.org/show_bug.cgi?id=886205
Bug 888083 - Do not #include inline-headers from non-inline headers
https://bugzilla.mozilla.org/show_bug.cgi?id=888083
Bug 880088 - Break the build on #include madness
https://bugzilla.mozilla.org/show_bug.cgi?id=880088
This kind of work is high-opportunity-cost. It involves a lot of
clobbering and try servering, and it doesn't get any JS engine bugs
fixed or features implemented.
-j
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
