On 11/15/2013 06:51 AM, Jason Orendorff wrote: > 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.
I'd go so far as to say it cannot change. If we wanted to retain the same level of type safety without templates we'd need to write (or macro-generate) 10x as much code, getting us right back to where we are now. > 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. The problem this mess is solving, at least in the GC, is that gecko needs to be able to inline barriers, UnmarkGray, and misc other stuff. Whenever we accidentally out-of-line anything in these paths we see a tremendous slowdown on dromaeo_dom and dromaeo_css, so we do have strong evidence that this optimization is critical. We hide as many of the internal GC details as possible behind magic number offsets, void*, and shadow structs, but this still -- particularly combined with templates -- leaves us with a tremendous amount of code in headers. I think our best hope for improving compilation time with these limitations is C++ modules. It wouldn't really improve the code layout mess, but would at least mean we only have to compile the massive pile of inlined code once. Cheers, Terrence > 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
