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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
