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

["Thun, Philipp" <philipp.thun@xxxxxxx>]

Thanks for all the ideas. I agree that introducing a cache would be beneficial and that we should expire the cache based on events (as Gunnar and Jens pointed out).

I also had another idea that I started implementing to find out whether it's doable or not. In order to avoid the creation of an individual TreeWalk for each resource, I propose that decoration requests are queued and then processed by a separate job that starts after a short delay (e.g. 100ms). As described in my first mail, the eclipse framework triggers n decoration requests (n = number of files) when opening a folder; with the new implementation these requests are queued and then processed at once by a single TreeWalk filtering for n paths. By re-measuring my test scenarios I can see another significant performance boost, but I have to fine-tune the implementation before submitting it for review.

Cheers,
Philipp


-----Original Message-----
From: Baumgart, Jens 
Sent: Montag, 17. Januar 2011 10:12
To: Gunnar Wagenknecht; Shawn Pearce; Thun, Philipp
Cc: (egit-dev@xxxxxxxxxxx)
Subject: RE: [egit-dev] Git decorator - current implementation

I like the idea of having a cache for decoration states.
But I do not like time outs for cache updates (1s, 2s, ...).
The cache could be updated incrementally based on resource change events and Git Index changes (currently there is no fine granular eventing for this).

Since this stuff will be complicated we should start with re-reading the DirCache instance only if the index changed (as proposed by Philipp).

--Jens


-----Original Message-----
From: egit-dev-bounces@xxxxxxxxxxx [mailto:egit-dev-bounces@xxxxxxxxxxx] On Behalf Of Gunnar Wagenknecht
Sent: Samstag, 15. Januar 2011 09:47
To: Shawn Pearce; Thun, Philipp
Cc: (egit-dev@xxxxxxxxxxx)
Subject: Re: [egit-dev] Git decorator - current implementation

Am 15.01.2011 04:04, schrieb Shawn Pearce:
> 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.

In terms of Eclipse resources it's relatively easy to build an in-memory
cache of the tree with all the information. Cache refresh/expire should
be alined with resource change events. Those are guaranteed to be
triggered when the resource (file/folder) changes on the file system
(either automatically or via a manually triggered refresh).

Performance for decorators is always a pain point. I remember that I
rewrote the ClearCase decorators at least four times. We ended up with
an in memory model that was populated/updated in the background (Eclipse
jobs). So for each IFile there was a ClearCaseFile and for each IFolder
there was a ClearCase folder. One last major improvement I remember was
reading a complete tree at once. Previously we had to issue ClearCase
calls (cleartool process on Unix/Linux, JNI/DLL on Windows) for each
resource individually (the API sucked). However, cleartool executable
was able to output the status for a complete tree at once in a
reasonable performance. Thus, I wrote an ANTLR parse for reading the
output and we ended up with great decorator performance.

-Gunnar


-- 
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev