On 15.09.2010 14:20, Johan Corveleyn wrote:
Some update on this: I have implemented this for svn_diff (excluding
the identical prefix and suffix of both files, and only then starting
to fill up the token tree and let the lcs-agorithm to its thing). It
makes a *huge* difference. On my
On Mon, Sep 20, 2010 at 11:52 AM, Branko Čibej br...@xbc.nu wrote:
On 15.09.2010 14:20, Johan Corveleyn wrote:
Some update on this: I have implemented this for svn_diff (excluding
the identical prefix and suffix of both files, and only then starting
to fill up the token tree and let the
On Sun, Sep 5, 2010 at 1:53 AM, Johan Corveleyn jcor...@gmail.com wrote:
On Tue, Aug 24, 2010 at 11:11 AM, Philip Martin
philip.mar...@wandisco.com wrote:
Johan Corveleyn jcor...@gmail.com writes:
On Sun, Aug 22, 2010 at 4:02 PM, Branko Čibej br...@xbc.nu wrote:
svn_diff uses basically the
On Wed, Sep 15, 2010 at 02:20:05PM +0200, Johan Corveleyn wrote:
Just to know how hard/fast I should pursue this: is there any chance
that a change like this could still make it into 1.7 (maybe even
backported to 1.6?), provided that the patch is of good quality and
all... ?
Depending on how
Johan Corveleyn wrote on Wed, Sep 15, 2010 at 14:20:05 +0200:
The patch is still very crude, with lots of code duplication, and
everything stuffed in one big function (and I may have overlooked some
edge conditions), so I don't feel it's ready to post yet (don't want
to waste people's time
On Sun, Aug 22, 2010 at 4:02 PM, Branko Čibej br...@xbc.nu wrote:
On 18.08.2010 00:59, Johan Corveleyn wrote:
Hi devs,
While Looking to improve performance of svn annotate [1], I found
that the current blame algorithm is mainly client-side bound, and that
most of its time is spent on svn
Johan Corveleyn jcor...@gmail.com writes:
Ok, thanks. In the meantime I saw that there is not that much
difference anymore between GNU diff and svn_diff, after running the
latter from a release build, and disabling my anti-virus (which makes
me wonder why my anti-virus slows down svn_diff
On Thu, Aug 19, 2010 at 11:38 PM, Johan Corveleyn jcor...@gmail.com wrote:
Feh, I just redid my apr_time_now+printf profiling with a release
build (of trunk), instead of a debug build, and that makes a *big*
difference. Total time of the svn_diff_diff call is now down to ~300
ms. Still a lot
Johan Corveleyn wrote on Fri, Aug 20, 2010 at 01:43:16 +0200:
If anyone has any more suggestions, short of installing a Linux
distribution and trying a linux profiler ...
Ask one of the other devs to do the profiling for you?
On Wed, Aug 18, 2010 at 3:44 PM, Johan Corveleyn jcor...@gmail.com wrote:
On Wed, Aug 18, 2010 at 12:49 PM, Stefan Sperling s...@elego.de wrote:
Can you show a profiler run that illustrates where the client is
spending most of its time during diff? That would probably help with
getting
-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: donderdag 19 augustus 2010 4:55
To: Subversion Development
Subject: Re: svn diff optimization to make blame faster?
I googled around a bit for C profilers on Windows. I found several
which seem useful
On Wed, Aug 18, 2010 at 12:59:21AM +0200, Johan Corveleyn wrote:
Hi devs,
While Looking to improve performance of svn annotate [1], I found
that the current blame algorithm is mainly client-side bound, and that
most of its time is spent on svn diff (calls to svn_diff_file_diff_2
from
Hi devs,
While Looking to improve performance of svn annotate [1], I found
that the current blame algorithm is mainly client-side bound, and that
most of its time is spent on svn diff (calls to svn_diff_file_diff_2
from add_file_blame in blame.c). Apart from avoiding to build
full-texts and
13 matches
Mail list logo
