Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-2016

Performance regression in 1.1.0 RC1/RC2

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Blocker
    • Resolution: Fixed
    • all
    • unscheduled
    • libsvn_client
    • None

    Description

      This was discussed on the mailing list, but no solution has been found yet. I'm
      filing this as an issue so it won't get lost:
      
      Matt Doran reported:
      In my testing of 1.1rc1 on windows (W2K SP4), I've noticed a big performance
      regression on 'svn status'. I'm not sure if this behaviour occurs in other
      commands, but I've examined svn status in some detail.
      
      I have a large repository that contains about 5000 files, with some
      directories containing hundreds of files. When I do an 'svn status' I get
      the following results:
      
      SVN 1.0.6: ~ 4 secs
      SVN 1.1rc1: ~ 38 secs !!
      
      I used the Filemon utility from sysinternals to try to determine what it
      happening. It looks like 1.1 excessively hits 'iconv' files. (e.g.
      windows-1252.so, utf-8.so, etc)
      
      In 1.0 it appears to hit these files early in the process, but then doesn't
      touch them while checking the *.svn-work and *.svn-base file.
      
      In 1.1 however for *every* hit on *.svn-work, etc you get multiple hits to
      various iconv file. They always accessed in the following order:
      * cp1252.so (attempted open once, not found)
      * windows-cp1252.so (opened, closed, stat'd 3 times)
      * _tbl_simple.so (opened, closed, stat'd 3 times)
      * cp1252.so (attempted open once, not found)
      * windows-cp1252.so (opened, closed, stat'd 3 times)
      * utf-8.so (opened, closed, stat'd 3 times)
      
      -----------------------------------------------
      The mailing list threads can be found here:
      http://www.contactor.se/~dast/svn/archive-2004-08/0131.shtml
      http://www.contactor.se/~dast/svn/archive-2004-08/0367.shtml
      
      Note: I've set the priority to 1 because the performance regression is really,
      really serious on Windows (don't know about Linux, but my guess is that it's
      noticeable there too). I did some tests with TortoiseSVN built against the 1.1.x
      branch of Subversion, and I can say that it's not usable that way. Even though I
      patched libapriconv which makes it even slightly faster in loading the *.so
      files than the original version, it still takes 10 times longer to get the
      status, start a commit, update or any other command translating paths/urls
      from/to UTF8. Without this fixed, I can't release a TortoiseSVN version linked
      with 1.1.0 of Subversion - if the explorer hangs for minutes people would kill me!
      

      Attachments

        Activity

          People

            Unassigned Unassigned
            steveking Stefan Küng
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: