On 04/15/2011 08:24 AM, Piotr Krukowiecki wrote: > On Thu, Apr 14, 2011 at 5:21 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: >> On 04/14/2011 03:38 PM, Piotr Krukowiecki wrote: >>> On Wed, Apr 13, 2011 at 12:43 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>> * mh/git-svn-automkdirs (2011-04-01) 1 commit >>>> (merged to 'next' on 2011-04-03 at 7fa4978) >>>> + git-svn: add an option to skip the creation of empty directories >>>> >>>> Should be safe, but I'd like an Ack from git-svn folks. >>> >>> I wanted to test performance of this change - what's the best way to do it? >>> >>> I tried some ideas, but rebase was too fast for performance measurements. >>> I did not have new commits, but just some old, already in trunk changes, which >>> I tried to rebase - probably it was just fast forward? >> >> The unhandled.log.gz file for trunk of our main project is 14 Mb and >> uncompresses to 233 Mb. About 90% of it consists of svn:mergeinfo >> properties for file that were copied or renamed within the repository; >> most of the rest is other random SVN file properties. >> >> With such a huge unhandled.log file, "git svn mkdirs" took about 10s for >> me. I believe that "git svn rebase" should take at least as long, even >> if it is a fast-forward. > > That might be the reason - my unhandled.log is 17MB (unpacked) and mkdirs > takes 0.5s Yes, it is also my assumption that parsing so much text in Perl is what causes the slowdown. But as long as git-svn insists on plonking so much information in unhandled.log but then handling it anyway, it seems like a good policy to prevent it from reading this file any more than necessary. And for me, the creation of empty directories is not worth 10s. (Even your 0.5s is pretty slow by git standards :-) ). An alternative might be to move the emptydir information from unhandled.log to a separate file. The "empty_dir" lines in my unhandled log are only about 0.1% of the file contents, and should be parseable in a negligible amount of time. But moving the data would presumably have implications for backwards compatibility. [Are there any design documents for git-svn? I have had a hard time deciphering the code and understanding what data it stores and where.] Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html