[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