Again, how many other similar wins are we leaving on the table because they're only 10s on a clobber build? It's of course hard to know, which is why I've suggested the (number of useful lines of code) / (total lines of code included) ratio as a meaningful metric.
But I'm completely OK with focusing on the bigger wins in the short terms and only reopening this conversation once we'll be done with the big items. Benoit 2013/9/8 Mike Hommey <m...@glandium.org> > On Sun, Sep 08, 2013 at 08:52:23PM -0400, Benoit Jacob wrote: > > We have many other headers including <algorithm>; it would be interesting > > to compare the percentage of our cpp files that recursively include > > <algorithm> before and after that patch; I suppose that just a single > patch > > like that is not enough to move that needle much, because there are other > > ways that <algorithm> gets included in the same cpp files. > > > > I do expect, though, that the 23 ms overhead from including <algorithm> > is > > real (at least as an order of magnitude), so I still expect that we can > > save 23 ms times the number of cpp files that currently include > <algorithm> > > and could avoid to. > > 23ms times 6000 sources is about 2 minutes and 20 seconds, if you don't > account for parallelism. If you count 6 processes compiling at the same > time on average, that's about 23s on a clobber build. > And according to the .o.pp files in my recently built fennec, we include > algorithm in less than 3000 files. So we'd be looking at about 10s of > overhead including algorithm on a clobber build. On a 20-something > minutes build. > I'd say there's not much to worry about here. > > Mike > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
