Investigation of slow performance with bringing up the show log dialog

Hi,

I'm currently investigating a presumably performance regression when 
comparing TSVN 1.8 with TSVN 1.9 performance.

The difference I'm seeing is in the following case:

1. Bring up the merge dialog on a WC
2. Select another branch to merge the changes from
3. Click the Show log button to select the revisions to merge from that 
branch

In TSVN 1.8 this took only a few seconds (at most). In my current test 
case using TSVN 1.9.4 the same step was measured to take 13-15s.
(Note that the comparisons were done over a year ago - I didn't 
precisely measure TSVN 1.8.12's current performance so things might be 
off or I might actually misremember --- so don't take the assumption of 
the performance regression for granted pls).

I've been tracing down the TSVN 1.9.4 code and see that the call to 
svn_client_mergeinfo_log2() takes up all the time (and in there 
svn_ra_serf__context_run_one()).

The parameters TSVN is passing on to svn_client_mergeinfo_log2() seem to 
request the entire range of all mergeinfos: (m_startrev: 214331 (which 
equals HEAD for the repository); m_endrev: 1).
In logs_for_mergeinfo_rangelist this translates to param2: 184222, 
param3: 213776 and limit being hardcoded to 0 in SVN.

 From this I conclude that TSVN requests the entire list of all 
revisions rather than only a subset of the range. Is that correct, or 
did I miss something?
If so, I'm wondering why this is necessary and whether there's no other 
way around it, since the Show log dialog in the end only lists a subset 
of this range (presumably the last 100 entires?).

In addition to this: I'm wondering why there's no caching logic involved 
here. I'd assume that for these common requests, TSVN would not query 
the server again for subsequent requests for the same log information.

-- 
Regards,
Stefan Hett

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3180350

To unsubscribe from this discussion, e-mail: [[email protected]].