Re: [Monotone-devel] Call for testing: nvm.experiment.no-split-path

[Derek Scherger]

Zack Weinberg wrote:
> That's a good sign.  Unfortunately I cannot reproduce it myself - on
> the aforementioned beefy amd64 box, I'm seeing a very small but
> consistent slowdown on the same test (4m20 before, 4m21 after).
> oprofile is not cooperating with me (zero samples recorded, no matter
> what I do), so I don't know why.

On my core2 duo box regenerate_caches is about 4 seconds slower with
your changes. Not sure why it would be faster on my pentium-m laptop.

I still like your change though and it doesn't seem to be causing any
major slowdowns.

> Having the utf8 copy constructor jump up in the profiles is to be
> expected; this _is_ doing more copying around of utf8s.  [Vocab items

Yeah, I wasn't all that surprised by it.

> in general seem to have a lot of extra gubbish attached to them - .ok
> booleans, symtabs, and now Tim's made them all double indirect - whose
> value I really have to question...]

I'm no so sure that immutable_string is helping either. For example I
did see immutable_string::get showing up high in a few oprofiles a while
ago. I was fiddling with an UNLIKELY for the null case but didn't get
far enough with that to decide if it was good or not. It's not showing
up in gprof profiles on the core2 box at the moment though.

The profiles I have do seem to be pretty consistent in showing the
dir_map lookups at or near the top at around 8-10% of the total time. I
think Tim changed this to a "hybrid_map" but it seems like there still
may be room for improvement there.

>> I'll try a few initial pull runs and let you know how they go as well.

Unfortunately things are not cooperating tonight... oprofiled is dying
on me, gcc -pg is generally failing to produce gmon.out's and user times
are coming up higher than real times... Woe is me.

Cheers,
Derek