[darcs-devel] [issue1731] performance regression in check/repair (2.4.x)

Reinier Lamers bugs at darcs.net
Sat Jan 16 21:04:25 UTC 2010


Reinier Lamers <tux_rocker at reinier.de> added the comment:

Op zaterdag 16 januari 2010 20:08 schreef Jason Dagit:
> Jason Dagit <dagitj at gmail.com> added the comment:

>For the failed check, when I run that case manually I get this output:

Hmmm, does it succeed when you run it manually, but fail when you run it from 
darcs-benchmark? Why?

> Another interesting bit, is that everything I snipped out between 
replayRepository' and applyAndFix contributes 0.0% to the the individual and 
> inherited times, yet when we get to applyAndFix only half the time is spent 
at or below applyAndFix.  I think that means the rest of the time 
> is spent mainly in isGZFile, fsCreateHashedFile, and hashedTreeIO (glancing 
at the profiling output also makes me think this).

isGZFile is defined in ByteStringUtils, so I'd expect it to show up in the 
profile. I can't find any occurrences of the string "fsCreateHashedFile" in 
the darcs source. hashedTreeIO is from hashed-storage, so may indeed eat a lot 
of time without showing up in the profile.

It may help to build without optimization and profile the unoptimized 
executable. While such a profile reflects less accurately what happens in an 
optimized executable, it may contain entries for some functions that do not 
appear in the profile of an optimized build due to inlining. It could be that 
isGZFile has been optimized away in this manner.

----------
nosy: +tux_rocker

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/issue1731>
__________________________________


More information about the darcs-devel mailing list