On 03.01.2017 16:44, Stefan Hett wrote:
> 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?
done in r27643.
>
> 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).
it's not necessary. It once was to get the branch-from revision, but
that didn't work as expected.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=3199336
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2017-01-07 02:42:14 CET