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

Re: faster client pre-1.0: decrease number of files&folders in .svn

From: solo turn <soloturn99_at_yahoo.com>
Date: 2003-02-10 17:07:47 CET

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

This is an archived mail posted to the Subversion Dev mailing list.