monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Call for testing: nvm.experiment.no-split-path
Date: Sat, 23 Jun 2007 19:09:22 -0500

On Sat, 2007-06-23 at 00:22 -0600, Derek Scherger wrote:
> 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.

Eh, when I added it I *thought* it was an improvement, but it's entirely
possible I missed something (particularly since time(1) was giving
completely bogus results, so all I had to go on was percentages of
various things). Please feel free to take it back out if you think it
doesn't actually help that much.

> 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.

...incidentally, I just discovered that the g++ in Ubuntu Breezy
("4.0.2 20050808 (prerelease)") doesn't have a default constructor for
tr1::unordered_map::iterator, which breaks hybrid_map.


-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net





reply via email to

[Prev in Thread] Current Thread [Next in Thread]