Re: [Monotone-devel] couple of things

[Zack Weinberg]

On Wed, Feb 13, 2008 at 7:21 AM, Markus Schiltknecht <address@hidden> wrote:
>  Cool, thanks. I've just looked into nvm.ee again, did a propagate and
>  removed inclusion of app_state.hh from inodeprints.cc.
>
>  I've checked the selectors, if we can remove the app_state there. As
>  well as tried to get rid of it from lua_hooks. Both attempts failed,
>  comments added to README.encapsulation.

Thank you.

I think I know how to get it out of the selectors, as part of getting
the workspace object out of the app_state, but that code is really
messy and I'm not sure I'm going to succeed.  That's the 5% that I'd
like to do before the branch lands.

As for lua_hooks, my current feeling is that if we can get app_state
down to just a wrapper around the options and lua_hooks objects, we
could then change the lua code that cares to work with those two
separately.  I'd like to use upvalues instead of an on-the-side map,
too.  I don't plan to do that before merging the branch, unless it's
ridiculously easy after the above.

>  Then, I've also measured the resulting lines of code for intermediate
>  files. For some reason, I only got .s files with --save-temps. No .ii
>  files. Anyway, those already show enough gains in various files, IMO.
>  While only few files have more lines, most have less, which stands for
>  better encapsulation, I think. That was the point of it.

Cool beans.  It's odd that you didn't get .ii files though.  I'm
guessing the .s file reductions are going to be mostly redundant
template instantiations that aren't being generated anymore, which if
nothing else, makes life easier for the linker.  (Someone who is
better with C++ than me really should take a chain saw to vocab.hh.)

>  Compile time didn't really reduce. On my box, nvm compiles with 'make
>  -j3' in 613.8 seconds, where as nvm.ee compiles in 601.5 seconds. That's
>  not quite 2% less, which is probably just noise. (Dropped system caches
>  before as well as ccache, CXXFLAGS: "-O2 -Wall -g -save-temps").

Hm, you got this with -j3? We haven't got any really slow individual
files, so either it's all link time, or you should be multiplying the
difference by 3.

>  So far my current review, I'm all for landing that branch very soon.

Thanks!
zw