Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Investigation of slow performance with bringing up the show log dialog

Project highlights: :. Download .: :. Support .: :. FAQ .: :. Translations .: :. Donate .: :. Report Bug .:

tortoisesvn
Discussion topic

Back to topic list

Investigation of slow performance with bringing up the show log dialog

Author Stefan Hett <stefan at egosoft dot com>
Full name Stefan Hett <stefan at egosoft dot com>
Date 2016-07-27 03:43:19 PDT
Message 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

« Previous message in topic | 1 of 6 | Next message in topic »

Messages

Show all messages in topic

Investigation of slow performance with bringing up the show log dialog Stefan Hett <stefan at egosoft dot com> Stefan Hett <stefan at egosoft dot com> 2016-07-27 03:43:19 PDT
     Re: Investigation of slow performance with bringing up the show log dialog Stefan Hett <stefan at egosoft dot com> Stefan Hett <stefan at egosoft dot com> 2016-08-02 04:54:21 PDT
         Re: Investigation of slow performance with bringing up the show log dialog steveking Stefan Küng 2016-08-02 13:12:03 PDT
             Re: Investigation of slow performance with bringing up the show log dialog Stefan Hett <stefan at egosoft dot com> Stefan Hett <stefan at egosoft dot com> 2016-08-03 03:40:53 PDT
             Re: Investigation of slow performance with bringing up the show log dialog Stefan Hett <stefan at egosoft dot com> Stefan Hett <stefan at egosoft dot com> 2017-01-03 07:44:20 PST
                 Re: Investigation of slow performance with bringing up the show log dialog steveking Stefan Küng 2017-01-06 17:42:03 PST
Messages per page: