Re: svn_repos_get_logs3 and unbounded memory use

C. Michael Pilato wrote:
> Garrett Rooney wrote:
>> So, just to see what the impact would be like, I implemented this the
>> "easy" way, not keeping any history objects open at all, just doing
>> the open/prev/prev thing each time we need to move back. On my test
>> case (which runs log on about 1200 paths in a repository that's got
>> 867 revisions in it) this results in about a 20% speed hit, with max
>> memory usage (via the oh-so-scientific "look at the output of top"
>> method of measuring) capping out at around 3 megs, as opposed to about
>> 250 megs the old way of doing things.
>
> As I noted on the phone a few minutes ago, my opinion runs thusly: if
> typical real-world use-cases (say, < 10 paths passed to 'svn log') don't
> suffer noticably from this approach, then the fix is fine with me -- it
> solves memory problems for all use-cases, even if the obnoxious cases
> suffer a 20% hit in speed. At least the operations (eventually)
> complete successfully.

I remember that one Subversion UI client (don't remember which one
exactly) passes multiple paths/urls to svn_client_log3(), even if the
user only wan't the log for one file/folder. It does this to get the
additional information on what happened to the same file/folder on all
tags/branches.

So I guess, if there are many branches and tags, that number of passed
paths will grow too (probably way beyond 10).

Not that I'm not ok with your approach here, just wanted to tell you
why/where/how this can easily happen.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org