Re: Entries caching & Performance

Brandon Ehle <behle@pipedreaminteractive.com> writes:

> On my working copy of 21011 files in 3528 directories, roughly 81%
> of the time is spent doing either IO or CPU intensive operations
> reading XML data in XML_Parse() & XML_ParseBuffer(). Roughly 76% of
> this time comes from svn_wc_entries_read. Talking to sussman and

For which Subversion operations? Which version of Subversion?

> pilchie on IRC revealed that we are currently doing caching of
> entries reading only on commits and status. Is anyone working on

That's not correct, entries are cached for all operations. At present
operations that modify the working copy will repeatedly *write* the
entries file, but it does not get read repeatedly. Writing happens
repeatedly because a) that's how it worked originally, and b) if it
didn't then an interrupted operation would lose all its modifications.
(I know interrupted checkouts cannot be restarted, but that's a bug
that needs to be fixed.)

Obviously every relevant entries file has to be parsed once. Are you
seeing the same file parsed repeatedly? How many times does
svn_wc_entries_read go on to call read_entries?

> implementing cached entries readings for updates & checkouts? This
> could possibly eliminate a large portion of the time spent during
> updates.
>
> The other half of the time spent comes from ne_xml_parse. I am not
> sure how this could be made faster short of replacing expat with
> something faster.

Is there such a thing? I don't know whether expat is fast or slow,
but simply asking for it to be replaced with something faster isn't
much help unless you can identify something that is faster :)

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org