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

Re: Entries Cache Performance

From: Brandon Ehle <azverkan_at_yahoo.com>
Date: 2002-11-26 19:47:10 CET

Greg Hudson wrote:

>On Tue, 2002-11-26 at 11:18, Brandon Ehle wrote:
>
>
>>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.
>>
>>
>
>Yeah, those are the two basic strategies. First, switch to hand-parsing
>the date, which shouldn't be too difficult; if that doesn't cut down the
>time spent in svn_time_from_cstring sufficiently, switch to storing
>dates in the entries file as decimal apr_time_t values. (Which is less
>readable, but simple and fast.)
>
>
Ok, I am going to try and implement a faster svn_time_from_cstring today
and see what kind of results I get.

>> 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.

> Which platform?

This was run on RedHat 8.0.

> You may like to try the following patch. It should parse the file
> only once when there is a write lock.

I'm seeing about a 14% speed boost with this patch.

> /* We ask for the deleted entries if there is a write lock on the
> basis that we will eventually need these when we come to write.
> Getting them now avoids a second file parse. However if we don't
> ever write it does use more memory. */

But something odd is happening, I am seeing a memory *savings* after applying this patch, unless of course I am reading /proc wrong?

Before Patch (avg time is 1.85 seconds)
=========
VmSize: 15048 kB
VmLck: 0 kB
VmRSS: 9756 kB
VmData: 8012 kB
VmStk: 144 kB
VmExe: 64 kB
VmLib: 4328 kB

After Patch (avg time is 1.62 seconds)
=========
VmSize: 11736 kB
VmLck: 0 kB
VmRSS: 6560 kB
VmData: 4700 kB
VmStk: 144 kB
VmExe: 64 kB
VmLib: 4328 kB

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 26 19:46:10 2002

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.