[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-11-26 18:03:58 CET

Brandon Ehle <azverkan@yahoo.com> writes:

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

Entries caching is working, before caching the XML_Parse would have
been called lots of times for each file. As I explained earlier,
there are two sets of entries and the order in which the sets are
requested determines whether the file needs to be read twice.

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

Index: subversion/libsvn_wc/lock.c
===================================================================
--- subversion/libsvn_wc/lock.c (revision 3902)
+++ subversion/libsvn_wc/lock.c (working copy)
@@ -299,7 +299,11 @@
       apr_hash_index_t *hi;
       apr_pool_t *subpool = svn_pool_create (pool);
 
- SVN_ERR (svn_wc_entries_read (&entries, lock, FALSE, subpool));
+ /* 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. */
+ SVN_ERR (svn_wc_entries_read (&entries, lock, write_lock, subpool));
 
       /* Use a temporary hash until all children have been opened. */
       if (associated)
@@ -317,7 +321,7 @@
 
           apr_hash_this (hi, NULL, NULL, &val);
           entry = val;
- if (entry->kind != svn_node_dir
+ if (entry->deleted || entry->kind != svn_node_dir
               || ! strcmp (entry->name, SVN_WC_ENTRY_THIS_DIR))
             continue;
           entry_path = svn_path_join (lock->path, entry->name, subpool);

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

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 26 18:04:52 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.