On 8/2/2016 10:11 PM, Stefan Küng wrote:
> On 02.08.2016 13:54, Stefan Hett wrote:
>> Hi,
>>
>> any idea/word on the issue pointed out in the mail here:
>> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3180350
>> ?
>>
>> Any idea whether this should/could be improved on TSVN's side? I'd be
>> willing to spend some time on writing/proposing a patch, but it would
>> certainly help if someone with a deeper knowledge on the TSVN
>> design/code could review my investigation and maybe point me to the
>> right/best way to deal with the case.
> Well, TSVN really calls svn_client_mergeinfo_log2() with the full rev
> range. It has to: it can't know the range before calling that function.
> SVN itself will stop where the branch was created from.
> Also, with a current svn server, that call should not take much time at all.
>
> Not sure how you would improve that situation...
>
> Stefan
>
Finally got back to the topic.
Performance measurements done in detail this time:
- Server was tested with SVN 1.8.16, 1.8.17 and 1.9.5 (aka: VisualSVN
3.3.7, 3.3.8, 3.5.7).
- Client tests were done using TSVN 1.8.12 and TSVN 1.9.5
Independent from the server version using TSVN 1.9.5 bringing up the
merge log dialog took always around 20s while with TSVN 1.8.12 it was
available almost instantly.
Checking on the code side in CLogDlg::LogThread() I realize that TSVN
used to call svn_client_mergeinfo_get_merged() in 1.8.x where TSVN 1.9.x
calls svn_client_mergeinfo_log2() now.
Discussing the issue on IRC with Bert, brane and danielsh, in my
understanding one of the differences of the newly used
svn_client_mergeinfo_log2() is that this retrieves all log details about
merged revisions, while svn_client_mergeinfo_get_merged() only retrieves
a list of revisions (without additional data).
The callback function (mergedrevsreceiver) used in TSVN 1.9 only makes
use of the revision number, as far as I can tell, so all the retrieved
additional data is unused (or did I miss something?). This also makes
sense IMO since the actual log data is then used via TSVN's cache logic
later.
That said, wouldn't it be reasonable to change that code and use
svn_client_mergeinfo_get_merged() as it used to do in TSVN 1.8.x?
In my case the performance impact is quite high because in my test case
there are roughly 13.000 revisions retrieved by that call which is quite
a lot of work for the server to fetch and transmit all of the log data.
As a proof of concept I quickly replaced the new code in TSVN 1.9 with
the previous approach from TSVN 1.8 and confirmed the performance being
back in line with how TSVN 1.8 behaved (see attached patch).
Please note that the attached patch is really just a proof-of-concept. I
didn't do a thorough code review (simply copied over the old code from
TSVN 1.8 to TSVN 1.9). One obvious issue with the patch is that it
doesn't take the start/end revisions into account, for example (and I
didn't review whether this is actually necessary or not).
--
Regards,
Stefan Hett
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3199070
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2017-01-03 16:54:09 CET