[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
