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

why is svn add slow?

From: Robert Pluim <rpluim_at_bigfoot.com>
Date: 2003-02-23 17:58:17 CET

Because it rereads _and_ rewrites the entries file for every file
added, and locks and unlocks the directory it's working on for every
file, even when all the scheduled adds are in the same directory.
I've done a few tests, and changing to locking, reading and writing
once per dir speeds up svn add by about 30x. The question I have is,
what is the best way to improve the current code:

1) Change svn_client_add to remember the directory it was last working
   on, making sure it's cached the entries file from the previous time
   around? (where would it cache it? The pool it's passed might not
   exist next time round).

2) Add an svn_client_add_in_dir, where you pass an apr_array where all
   the targets are guaranteed to be in the same dir, and make
   svn_cl__add call that?

3) Some other way to make the entries file be cached? I haven't fully
   understood how the set field of svn_wc_adm_access_t is used yet.

I'm not sure either way. (1) feels icky, since it requires caching
unbeknownst to the client code. (2) feels cleaner, but requires
svn_cl__add to sort through all the scheduled adds, splitting them
based on parent directory.

What do you think?

Robert

-- 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 23 18:03:03 2003

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.