Re: [egit-dev] Git decorator - current implementation

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Fri, Jan 14, 2011 at 08:02, Thun, Philipp <philipp.thun@xxxxxxx> wrote:
> I worked on the Git decorator now for some time and could improve the
> performance with some minor tweaks. Nevertheless I want to start a
> discussion about the current implementation of the decorator as there are
> several bugs open that deal with the bad performance of the decoration.
>
> From my analyses I see mainly two problems:
>
> To decorate a single resource, a "full-blown" TreeWalk is created with a
> filter for this single file. The performance of this decoration thus depends
> on the size and complexity of the overall repository; decorating a resource
> in a small repository is fast while decorating a single file in a huge
> project becomes slow. Maybe we have to come up with some solution that does
> not require building a full TreeWalk…

If you know you have a file in hand, you can avoid the TreeWalk and
just do a binary search on the DirCache itself.  That will avoid some
allocation and may be faster.  Unfortunately you need the resource
state from the WorkingTreeIterator too, and that currently needs a
TreeWalk in order to move to the requested file.  But maybe that can
be worked around by providing another way to build a
WorkingTreeIterator.

However, if its a directory that you are decorating, you probably need
to use the TreeWalk to go through the contents.  I don't see a good
way to avoid it.

Do you know what part of the decoration is slow when its a big
repository?  Reading a big repository's DirCache can take time, and
our decorator does it on each path to decorate.  Caching the DirCache
(as the other thread is talking about doing) would help.  But I don't
know if that helps enough.

> When a decoration is (re-)triggered, e.g. by opening a folder in the package
> explorer, each resource affected by this is handled independently. For
> example, when browsing a folder containing 100 files, 100 TreeWalks are
> created and traversed (as described above). This is caused by how Eclipse
> triggers these decorations, but it would be faster, if a set of resources
> could be decorated at once or if we could somehow manage to use a TreeWalk
> for more than a single file (e.g. by loosening the filter and caching the
> results somewhere).

I have no idea how to program the Eclipse decorators.  Caching the
results may help, but we run into a problem with figuring out when to
expire the cached data to ensure we are showing live information.  It
might work to just cache the data for 1 second, and discard if its
older than that, under the assumption that a user will accept a 1
second lag on decorator status in exchange for a faster decorator.

-- 
Shawn.