Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] [egit-dev] Expected performance profile of staging changes and committing then

2012/11/6 Markus Duft <markus.duft@xxxxxxxxxx>
On 11/06/2012 04:18 PM, Robert Munteanu wrote:
> Hi Markus,
> On Tue, Nov 6, 2012 at 12:14 PM, Markus Duft <markus.duft@xxxxxxxxxx> wrote:
>> On 11/06/2012 10:14 AM, Tomasz Zarna wrote:
>> [1]
> Thanks for the detailed information and for raising that bug.
> Hopefully someone can look into properly fixing this.

you might be interested in these changes i just pushed:


they belong together and bring staging/unstaging time down to a millisecond for me :D ofc this is still kind of a (dirty?) hack ;) however all unit tests run through with it and i did not observe any obvious problems with it. unit tests run a little slower since the Repository constructor now already causes an index read, but i don't think this will do harm in real-world scenarios as Repository is not a thing that is constructed all the time from scratch. Experts may now prove me wrong ;)

For still unknown reason events don't exactly behave as i'd expect them sometimes. it happened that the code did not detect changes from one to the other index state. i was not really able to reproduce this case, but still... i don't know exactly yet. in such a case the refresh button in the staging view would trigger a full refresh. Sometimes a full refresh is triggered too, which i don't fully understand either, but most of the time it's fast ;)

The initial construction of the IndexDiffCacheEntry still does a full scan, so does a RefChangedEvent (caused by every ref update (commit, rebase, ...)).

> I know little about the internals of {j,e}git but I'd be more than
> happy to test any proposed fixes on my repository, add profiler traces
> and whatever else is needed.

Would be cool if you can build it yourself. if you can't, [3] is a pre-built snapshot with my change (and all (except one) changes from [4]).


(it's an update site archive, so you should be able to just install from it into your eclipse ;))

we need to keep the ability to do a full refresh also for the case when some git operations are done by
another process than the Eclipse instance we are looking at. E.g. you may want to do some advanced
git operations not yet available in EGit using native git which won't send these events.

Back to the top