[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

On 11/06/2012 10:14 AM, Tomasz Zarna wrote:
>> Both jobs are triggered by the IndexChangedEvent i guess (or at least the re-indexing).
>> This event is IMHO just too stupid, as it carries no information about /what/ changed.
> 
> Out of curiosity, is there a bug for that?

Ofc, there is the very long standing JGit bug [1]. It is there for over a minute now, so i wonder why nobody fixed it yet :D

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=393642

> 
> Cheers,
> Tomasz
> 
> On Tue, Nov 6, 2012 at 8:15 AM, Markus Duft <markus.duft@xxxxxxxxxx <mailto:markus.duft@xxxxxxxxxx>> wrote:
> 
>     On 11/05/2012 05:38 PM, Robert Munteanu wrote:
>     > Hi,
>     >
>     [snip]
>     > Some background information: my repository is pretty large, 17000
>     > files, 9000 directories, 1.2GB total size, 2.5 MB for .git/index. My
>     > computer is reasonably fast ( SSD, i7, Linux ) so I wouldn't look
>     > there for performance problems.
> 
>     Hi!
> 
>     We have a similar repo - ~30000 files, 1.1GB total, 5.5MB index. I use a linux workstation with 16 cores, 12G RAM and a spinning 10k rpm disk.
> 
>     >
>     > I don't use the commit dialog since the performance is too slow [1]
>     > so I fell back to using the staging view.
> 
>     Me too - i already contributed some changes to EGit vastly increasing the performance of the staging view, as it was too slow for me too ;)
> 
>     >
>     > When I use the staging view I observe the following:
>     >
>     > 1. Staging changes involves at least two background jobs:
>     >
>     > - Git repository refresh
>     > - Re-indexing repository $NAME
> 
>     Both jobs are triggered by the IndexChangedEvent i guess (or at least the re-indexing). This event is IMHO just too stupid, as it carries no information about /what/ changed, i just tells that /something/ in your 2.5MB index changed, thus EGit has to recalculate everything. This is an issue for me too, as you can imagine, as our index is even bigger :/
> 
>     >
>     > 2. Committing changes involves at least three background jobs
>     >
>     > - Committing changes ( which is pretty fast )
>     > - Re-indexing repository $NAME
>     > - Building commit info
> 
>     Same here, the re-indexing is triggered by the index change. I profiled those jobs a lot, and i guess for what they do, they are pretty fast. The problem is what they do - they are forced to do much to much, as the information about the actual changes is missing.
> 
>     >
>     > Both these operations take a lot of time and I would expect them to be
>     > instant, since I'm changing 2 files out of 17.000 and egit knows which
>     > files have changed and doesn't need to recalculate the whole
>     > repository state.
> 
>     This describes what we all would like it to be :D
> 
>     Regards,
>     Markus
> 
>     >
>     > Am I missing out on something? I've captured yourkit snapshots of both
>     > the 'stage' and 'commit' operations and I can provide them if needed.
>     > Before that I'd like to know whether this is expected and I should
>     > stop worrying and start drinking more tea or considered a performance
>     > bug and should be entered in bugzilla .
>     >
>     > Thanks,
>     >
>     > Robert
>     >
>     >
>     > [1]: 331273: Commit operations opens and reads almost all files
>     > https://bugs.eclipse.org/bugs/show_bug.cgi?id=331273
>     >
>     > --
>     > Sent from my (old) computer
>     > _______________________________________________
>     > egit-dev mailing list
>     > egit-dev@xxxxxxxxxxx <mailto:egit-dev@xxxxxxxxxxx>
>     > https://dev.eclipse.org/mailman/listinfo/egit-dev
>     >
>     _______________________________________________
>     egit-dev mailing list
>     egit-dev@xxxxxxxxxxx <mailto:egit-dev@xxxxxxxxxxx>
>     https://dev.eclipse.org/mailman/listinfo/egit-dev
> 
>