{"thread":{"id":"37823","subject":"Re: Anomaly with the new code - Re: git-svn performance","startedAt":"2014-10-27T23:08:58Z","lastAt":"2014-10-27T23:08:58Z","messageCount":1,"participants":["Hin-Tak Leung"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"251136","messageId":"1414451338.51943.YahooMailBasic@web172303.mail.ir2.yahoo.com","threadId":"37823","inReplyTo":null,"subject":"Re: Anomaly with the new code - Re: git-svn performance","fromName":"Hin-Tak Leung","fromEmail":"htl10@users.sourceforge.net","sentAt":"2014-10-27T23:08:58Z","receivedAt":"2014-10-27T23:08:58Z","isPatch":false,"sender":{"key":"htl10@users.sourceforge.net","avatar":null},"body":"------------------------------\nOn Mon, Oct 27, 2014 06:38 GMT Eric Wong wrote:\n\n>Which SVN version are you using?  I'm cloning (currently on r373xx)\n>https://svn.r-project.org/R using --stdlayout and\n>unable to see memory growth of the git-svn Perl process beyond 40M\n>(on a 32-bit system).\n>\n>I also tried http:// (not https), svn+ssh:// on my local (64-bit) system\n>and did not see memory growth, either:\n>\n>    http://mid.gmane.org/20141027014033.GA4189@dcvr.yhbt.net\n>\n>I'm using svn 1.6.17 on Debian stable in all cases.\n\nThe memory consumption does seem to go up a good deal after r48xxx -ish (the total\nbeing about 67xxx-ish now), when there are a fair number of branches. Seeing as\nyou seem to be able to make the memory consumption drops further,\nI'll rebuild git with dropping/adding those patches now.\n\nI also just realised \"/usr/bin/time -v git svn fetch --all\" also includes the periodic auto-\ngarbage collection from git itself if fetching more than a number of commits,\nso may not be accurate once git svn's memory consumption drops below\na certain level. Is there any way of coping with that?\n\nI made a 3rd clone yesterday - it took 8 hours 15 minutes, and \n\tCommand being timed: \"git svn fetch --all\"\n\tUser time (seconds): 6897.80\n\tSystem time (seconds): 18853.08\n\tPercent of CPU this job got: 86%\n\tElapsed (wall clock) time (h:mm:ss or m:ss): 8:14:00\n...\n\tMaximum resident set size (kbytes): 675436\n\nand fetching the next 8 commits:\n\n$ /usr/bin/time -v git svn fetch --all\n\tM\tdoc/NEWS.Rd\nr66871 = 0a7f50fc04dee174229513a0d80fecfcd12975ca (refs/remotes/trunk)\n...\n\tM\tdoc/manual/R-exts.texi\nr66879 = ede68f65df714c3ba283579d85105393c1eccc80 (refs/remotes/trunk)\nAuto packing the repository in background for optimum performance.\nSee \"git help gc\" for manual housekeeping.\n\tCommand being timed: \"git svn fetch --all\"\n\tUser time (seconds): 856.82\n\tSystem time (seconds): 29.78\n\tPercent of CPU this job got: 98%\n\tElapsed (wall clock) time (h:mm:ss or m:ss): 15:03.39\n...\n\tMaximum resident set size (kbytes): 791088\n\nand quite similar against the 2nd clone, but against the first clone (which were created\nby fetching every few days over a few years):\n\n\tCommand being timed: \"git svn fetch --all\"\n\tUser time (seconds): 518.00\n\tSystem time (seconds): 28.62\n\tPercent of CPU this job got: 98%\n\tElapsed (wall clock) time (h:mm:ss or m:ss): 9:16.84\n...\n\tMaximum resident set size (kbytes): 403160\n\nSo it seems the first clone is rather different from the recent ones. I haven't got round to compare\nthe branches yet - it is actually easier than I thought, since I only need to compare\nthe branch HEADs. (I already mentioned that trunk is different, due to a blank vs 3 word\ncommit message about 2 years ago - I reckon I might see similar issues in the other branches\n- I'll go and write a script to check that now).\n\nAll recent fetch were done with git 2.1.0 patched with the 6 patches I mentioned, on fedora 20\nx86_64.\n\nBTW, I have been meaning to ask - are you the same \"Eric Wong\" who maintained\nsome chinese packages on Debian some years ago? :-)\n"}]}