Re: Caching merged diffs



2009/7/20 Piotr Piastucki <leech miranda gmail com>:
> On Mon, Jul 20, 2009 at 2:44 AM, Kai Willadsen <kai willadsen gmail com>
> wrote:
>>
>> One downside to your method is that chunk position is part of the
>> cache. The most obvious issue with this is that any change that
>> inserts or deletes lines causes lots of rediffing. For example,
>> instead of typing a single character in your "meld filediff.py
>> meldapp.py" example, just hit enter.
>
> Yes, that's why I am fully in favour of your approach :)
> Just wanted to mention one rather minor (as the highlighting code should not
> change often) disadvantage.

Well, I decided that your approach was well worth it too. :)

I tested with a few different cases, and there are certainly benefits
to doing as little work as possible. For example, in the case of
tokenising the input text, just the splitting process can take a while
on large change blocks... and my approach doesn't skip that.

I've reworked your approach, and integrated my caching with it. I had
to change the cache eviction, and while it has some flaws, I think
it's pretty good without making the SequenceMatcher calls async or
getting overcomplicated.

Patches attached.

Kai

Attachment: 0001-Avoid-retagging-whole-textbuffers-if-diff-chunks-hav.patch
Description: Binary data

Attachment: 0002-Cache-inline-diff-results-to-avoid-rediffing-blocks.patch
Description: Binary data



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]