Re: Further diff optimization ideas

2011-05-13 Thread Stefan Fuhrmann
On 13.05.2011 10:44, Julian Foad wrote: Johan Corveleyn wrote: Ok, to wrap this up for now: r1102471 finally put these thoughts into notes/diff-optimizations.txt, with some of Stefan2's feedback/ideas integrated into it. Johan, thank you for writing down the ideas you've thought through so much

Re: Further diff optimization ideas

2011-05-13 Thread Julian Foad
Johan Corveleyn wrote: > Ok, to wrap this up for now: r1102471 finally put these thoughts into > notes/diff-optimizations.txt, with some of Stefan2's feedback/ideas > integrated into it. Johan, thank you for writing down the ideas you've thought through so much, where we can find them later, in ad

Re: Further diff optimization ideas

2011-05-12 Thread Johan Corveleyn
Ok, to wrap this up for now: r1102471 finally put these thoughts into notes/diff-optimizations.txt, with some of Stefan2's feedback/ideas integrated into it. I also added another, previously mentioned idea into the notes file, which I forgot to mention in this mailthread: --- 8< --- Avoid some ha

Re: Further diff optimization ideas

2011-02-22 Thread Johan Corveleyn
On Mon, Feb 21, 2011 at 8:55 AM, Stefan Fuhrmann wrote: > On 15.02.2011 01:42, Johan Corveleyn wrote: >> >> Hi, >> >> Here are some more ideas for optimizing "svn diff". Maybe I should >> start to write up a notes file, but for now I'm settling for a list in >> a mail. >> >> [ note: these ideas ar

Re: Further diff optimization ideas

2011-02-20 Thread Stefan Fuhrmann
On 15.02.2011 01:42, Johan Corveleyn wrote: Hi, Here are some more ideas for optimizing "svn diff". Maybe I should start to write up a notes file, but for now I'm settling for a list in a mail. [ note: these ideas are not original, other people have observed some of these as well (and discussed

Re: Further diff optimization ideas

2011-02-15 Thread Branko Čibej
On 15.02.2011 13:04, Johan Corveleyn wrote: >> In other news, why do we need our own hash function anyway? Or our own >> table or tree or whatever? NIH syndrome? > No idea, really. I'm probably not the guy you're expecting an answer > from :-), but: > - apr_hashfunc_default could be very useful her

Re: Further diff optimization ideas

2011-02-15 Thread Johan Corveleyn
2011/2/15 Branko Čibej : > On 15.02.2011 01:42, Johan Corveleyn wrote: >> 2) Faster hash function for hashing lines. [ Quick win ] >> >> - Currently, we use adler32 (after the line has been normalized). >> >> - GNU diff uses some simple bit shifting scheme, which seems to be a >> lot faster (maybe

Re: Further diff optimization ideas

2011-02-15 Thread Branko Čibej
On 15.02.2011 01:42, Johan Corveleyn wrote: > 2) Faster hash function for hashing lines. [ Quick win ] > > - Currently, we use adler32 (after the line has been normalized). > > - GNU diff uses some simple bit shifting scheme, which seems to be a > lot faster (maybe it has more hash-collisions, but