Hrmm, actually I just noticed that when I counted my directories
yesterday, I was including the .svn
stuff in the count,what I am really seeing is this:
Working Copy 1
=========
There are 4164 files in the working copy
There are 275 directories in the working copy
There are 271 .svn/entries files in the working copy
XML_Parse() is called 679 times
Of this XML_Parse() time, 42% is spent in svn_time_from_cstring(), and
21% is spent in svn_wc__do_update_cleanup() which is calling
write_entry() (19%).
Working Copy 2
=========
There are 1278 files in the working copy
There are 128 directories in the working copy
There are 107 .svn/entries files in the working copy
XML_Parse() is called 219 times
82% of the time is spent in XML_Parse() and below
Of this XML_Parse() time, 43% is spent in svn_time_from_cstring(), and
22% is spent in svn_wc__do_update_cleanup() which is calling
write_entry() (20%).
Which indicates the XML_Parse is getting run on average of twice per
entries file, plus a couple other calls of XML_Parse() from neon. Any
idea why the entries caching is not working for this case?
Also it appears that expat isn't the source of XML_Parse() being slow,
but rather Subversion's usage of it. Looks like svn_time_from_cstring()
is chilling in sscanf for 99% of its time. On the overall, right now
sscanf is about 33% of svn's time spent when doing a update on an empty
working copy. Any ideas on how to speed this up? Two things that come
to mind is a hand coded replacement for sscanf, or storing the time in
an alternate format where we don't need to use sscanf to parse it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 26 17:18:03 2002