| commit | 007bae457098407bcfc762c64b23f8b690a197c4 | |
| author | Thomas Wolf <thomas.wolf@paranor.ch> | |
| Fri, 2 Sep 2016 21:52:40 +0000 (2 23:52 +0200) | ||
| committer | Matthias Sohn <matthias.sohn@sap.com> | |
| Thu, 8 Sep 2016 21:34:32 +0000 (8 17:34 -0400) | ||
| tree | 283f4170b0a1c6fdb3ec0b0bf1668ee74c328410 | treesnapshot (tar.gz zip) |
| parent | 8d005606f73508917fb23b5ade4144304ac39442 | commitdiff |
Speed up context menu in staging view
The context menu in the staging view could take _very_ long to appear on
a folder node with many children. This was caused by (a) the quadratic
algorithm using lists, and (b) by the frequent re-allocations occurring
in one of those lists.
Fix by collecting the staging entries in a linked hash set, which offers
faster membership testing and (for this use case) better memory
management. Only convert to a list (as required by the structured
selection used) once all staging entries have been collected.
The context menu now appears quickly, even on large folders. However,
applying actions may now still take very long. For instance, selecting
"Ignore" on a (non-expanded) folder containing 50000 files tries to add
all those 50000 files one after the other to a .gitignore, which takes
ages. This is not fixed by this change; there is a long-standing TODO
for this in IgnoreOperation.
Bug: 500106
Change-Id: I03979d525618fbcf23c6d73c9f4ec3dbf4637d10
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
The context menu in the staging view could take _very_ long to appear on
a folder node with many children. This was caused by (a) the quadratic
algorithm using lists, and (b) by the frequent re-allocations occurring
in one of those lists.
Fix by collecting the staging entries in a linked hash set, which offers
faster membership testing and (for this use case) better memory
management. Only convert to a list (as required by the structured
selection used) once all staging entries have been collected.
The context menu now appears quickly, even on large folders. However,
applying actions may now still take very long. For instance, selecting
"Ignore" on a (non-expanded) folder containing 50000 files tries to add
all those 50000 files one after the other to a .gitignore, which takes
ages. This is not fixed by this change; there is a long-standing TODO
for this in IgnoreOperation.
Bug: 500106
Change-Id: I03979d525618fbcf23c6d73c9f4ec3dbf4637d10
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
| org.eclipse.egit.ui/src/org/eclipse/egit/ui/internal/staging/StagingView.java | diffblobblamehistory |