Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
all
-
None
Description
"svn blame" is very slow making it less useful than it could be. For example, on a file with about 380 revisions it is an order of magnitude slower (16x) than cvs annotate on the same source file (converted from CVS to SVN). The performance difference varies between files though, but in this case it was the difference between 44 seconds and 12 minutes. (If it was 0.1 seconds vs. 1.6 seconds, there would be no issue.) Optimally, svn blame is used frequently in large projects where it is useful to determine who wrote a particular piece of code or last touched it. Obviously, having a slow version is much better than no version, but when it takes 10 minutes to get a definitive answer, developers are much more likely to just ask everyone and waste time. What the minimal speed is, I'm not sure, but speeding it up by a factor of 5 or 10 would probably be sufficient to get back most of the functionality that is present with cvs annotate. If you hate it when users make suggestions about how to fix an issue, stop reading at this point (I hate that too). I'm not very familiar with SVN's architecture, but some ways it might be sped up without losing functionality: - caching the ownership state (on the server or the client) at periodic intervals for each file to reduce the number of versions that need to be retrieved - working from the most recent version (being requested) backwards to the oldest version requested might not improve speed because some spaces and blank lines are likely to carry over from even ancient versions, but if the user could specify a minimum number of lines that should be annotated (for example 80% meaning, stop going backwards when 80% of lines have a known owner) That's assuming there isn't a better way to improve the performance or some issue with the current svn blame design or algorithm.
Original issue reported by quinlan