[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: issue 2043 profiling data

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-09-06 01:39:55 CEST

Erik Huelsmann wrote:

>Ok. I ran tests to see what happens with issue 2043 (committing 300.000+
>files).
>
>When committing, this process happens:
>- the client collects (harvests) the targets it needs to commit;
>- an RA session is opened to do the actual commit.
>
>With gprof I found that the case described in the mail referenced by the
>issue, it takes hours to prepare for the commit, ie the client takes hours
>to complete the harvesting. Most of that time is spent in
>look_up_committable as seen from the diagram below:
>
>Each sample counts as 0.000999001 seconds.
> % cumulative self self total
> time seconds seconds calls s/call s/call name
> 93.32 328.51 328.51 324343 0.00 0.00 look_up_committable
> 0.97 331.92 3.41 2902088 0.00 0.00 svn_utf__is_valid
>
>
>The client has been running with 96%+ CPU for 4 hrs while collecting
>committables when an error occurs (because it cannot connect) and the client
>exits.
>
>There is one problem though: The program ran for about 4 hours, but the
>gprof table seems to suggest that only 328.51 seconds elapsed in
>look_up_committable (which is 93% of all time elapsed).
>
>Can someone help me explain the data above and the relation with the 'time'
>output which gives 229minutes?
>
>
I think gprof will show CPU time, while most of the wall clock time is
blocking in I/O. 'time' should actually tell you user, system and wall
clock time; which of them is 229 minutes?

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 6 01:40:17 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.