i did the analysis now from the other side, top down, the results
point to less files imo:
- find a more intelligent locking strategy
(current strategy seems to take 30%)
- throw away auth (not in the test case, but generally a good idea)
- throw away dirs
- reduce rest of the files
- remove/reduce the renames ... it seems the working
copy admin area is treated as the most precious
thing in the world ... which it is not, as it
can and must be reconstructable in any case.
in the worst case, you have to compute a diff
from HEAD to current working copy state with
just the knowledge of (1) HEAD file (2) working copy file
- "full file write" is not noticeable
i propose opening issues to tackle the points mentioned (in a first
step) ... and i am now somehow biased to put (in a second step) as
much as possible in a "client bdb" area. the server, which is the
most precious thing here, does not take measureable performance hit
at all, which is a very good sign.
but the following statement of the subversion top page:
"Costs are proportional to change size, not data size
In general, the time required for an Subversion operation is
proportional to the size of the changes resulting from that
operation, not to the absolute size of the project in which the
changes are taking place. This is a property of the Subversion
repository model."
dos NOT hold with the current working copy administrative area
design.
the details:
distribution of effort svn up, full update, chmod mostly removed,
down to systems calls (all numbers in %, rounded), total 280sec:
100 svn_client_update
94 svn_wc_crawl_revisions
reporter_finish_report
svn_repos_finish_report
svn_repos_dir_delta
90 delta_dirs
add_file_or_dir
41 add_directory
prep_directory
94 svn_wc__wnsure_adm
init_adm
30 svn_wc__make_adm_thing
80 svn_io_dir_make --> 100% mkdir
20 svn_io_file_open --> 98% open
23 init_adm_tmp_area
80 svn_io_dir_make --> 100% mkdir
20 svn_io_file_open --> 98% open
15 init_adm_file
88 svn_wc__close_adm_file --> 100% rename
12 svn_wc__open_adm_file --> 100% open
14 svn_wc__entries_init
--> close_adm_file --> 100% rename
6 svn_wc_adm_close
5 svn_io_write_version_file
5 make_empty_adm
3 svn_wc_adm_open
5 svn_wc__ensure_directory
39 close_file
svn_wc_install_file
76 svn_wc__run_log
76 svn_xml_parse, XML_ParseBuffer, contenProcessor,
doContent, startHandler
93 log_do_file_xfer, file_sfer_under_path
71 svn_io_file_rename
28 svn_subst_copy_and_translate
7 log_do_file_readonly --> 100% chmod readonly
17 svn_wc__entries_write
6 svn_wc__remove_adm_file
12 svn_wc__close_adm_file
11 svn_wc__merge_prop_diffs
13 close_directory
4 delta_files
2 delta_dirs
10 close_edit
many steps down to:
69 svn_sc__close_adm_file --> 100% rename, ~45sec
23 svn_wc__open_adm_file
7 apr_file_write_full
6 svn_wc_adm_close
this means for performance gain, given a 280sec runtime:
11 %, 32sec:
throw away subdirectories saves 80% of 40sec
what i don't get is:
1. svn_xml_parse takes 54sec, 36sec of this is "svn_io_file_rename".
2. why close_edit takes 16sec for open_adm file
distribution of effort svn up, empty update, chmod mostly removed,
down to systems calls (all numbers in %, rounded), total 62sec:
68 svn_wc_crawl_revisions
95 reporter_finish_report
svn_repos_dir_delta
close_edit
svn_wc__do_update_cleanup
recursively_tweak_entries
svn_wc__entries_write
53 svn_wc__close_adm_file --> 100% rename
32 svn_wc__open_adm_file --> 99% open (=13sec)
15 apr_file_write_full (=6sec)
4 reporter_set_path --> 100% svn_repos_begin_txn_for_update
29 svn_wc_adm_close
remove_lock
71 apr_file_remove (=13sec)
29 svn_io_set_file_read_write (=5sec)
what is noticeable:
- opening files takes twice as long as writing them.
- remove lock takes 30%
what i don't get is:
1. why "svn up" (ie. get info from server to client,
don't touch server) opens the repository for UPDATE?
2. why 21sec or 30% is "rename" in finish report, if there is no
change at all?
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 10 17:08:40 2003