Skip to main content

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

Hi,

I'm trying to find out whether using the performance profile of using
the staging view for staging and committing changes is as it is by
design or by lack of time to improve it.

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.

I don't use the commit dialog since the performance is too slow [1]
so I fell back to using the staging view.

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

2. Committing changes involves at least three background jobs

- Committing changes ( which is pretty fast )
- Re-indexing repository $NAME
- Building commit info

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.

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


Back to the top