solo turn <soloturn99@yahoo.com> writes:
> some profiling data for 512 directories test case, run time on stripe
> drive, duration 42sec:
>
> time (sec):
> 16.8 _rename
> 8.5 __open
> 5.69 chmod
> .99 _poll
> .41 _fdsync
Interesting. Which platform is this? Are those numbers CPU time or
elapsed time?
There are a lot of chmod calls to set read-write staus in order to
support Windows clients. Most of these are unnecessary for a Unix
client, I tried taking them out and the number of chmod calls for a
checkout was halved. I don't think it is a significant problem yet as
other things dominate, but one day I may be tempted to make these
calls platform specific.
I have been thinking about performance in terms of entries caching for
a while now, some of my ideas are in the file notes/entries-caching.
One of the problems is that a lot of the interfaces accept a const
char* path, and then query the physical filesystem to determine if the
path is a file or a directory, whether it is versioned or not, etc. I
think that a lot of this is redundant, and that we can make more use
of the information stored in the access batons, after all if a baton
has been opened then that path must be a working copy directory. Once
we have determined that a path really is a file, we should cache that
information.
In the meantime you may like to experiment with this patch, it should
reduce the number of times the entries file is written when checking
out or updating a directory.
Index: ../svn/subversion/libsvn_wc/update_editor.c
===================================================================
--- ../svn/subversion/libsvn_wc/update_editor.c (revision 4791)
+++ ../svn/subversion/libsvn_wc/update_editor.c (working copy)
@@ -792,7 +792,7 @@
SVN_ERR (svn_wc_adm_retrieve (&adm_access, db->edit_baton->adm_access,
db->path, pool));
return svn_wc__entry_modify (adm_access, NULL, &entry,
- modify_flags, TRUE, pool);
+ modify_flags, FALSE, pool);
}
}
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 8 11:51:45 2003