[GTK] Speedup TreeItem retrieval by removing redundant iterations #882 #904
Conversation
basilevs
force-pushed
the
issue_882_removeCountCheck
branch
5 times, most recently
from
1eed277
to
cc810ea
Compare
basilevs
changed the title
basilevs
force-pushed
the
issue_882_removeCountCheck
branch
from
cc810ea
to
56369ba
Compare
|
@SyntevoAlex please take a look, if possible. |
…ipse-platform#882 TreeItem and Tree have been checking indexes for bounds during indexed access and traversal. Such checks are slow as node size computation is an O(N) operation. As Tree already does iteration when retrieving a TreeItem by its index, and such iteration detects out-of-bounds problems, preliminary model bounds check is redundant. Also, bounds check is avoidable during iteration over a node - instead of an index, GTK iterator applies directly. Performance improvement proved by running org.eclipse.swt.tests.junit.performance.Test_org_eclipse_swt_widgets_Tree.jfaceReveal(). In test jfaceReveal[Shape: STAR, virtual: true]: 10_000 elements: 501_378_662ns -> 218_583_468ns 100_000 elements: 52_781_899_817ns -> 20_872_245_796ns (-60%)
basilevs
force-pushed
the
issue_882_removeCountCheck
branch
from
56369ba
to
da365f1
Compare
|
I can review it a few days later. |
I think you are the only reviewer left, given @akurtakov is reluctant and lack of other recent contributors in Tree.java Anyway, this is not a critical bug, so please take your time. |
|
FWIW, I am not 100% out but non-UI things have far higher priority for me. |
|
I feel that #930 is significantly more important, so I'll have to handle it first. |
|
@SyntevoAlex are there any news? |
|
Sorry, too many things to do and too little time. |
|
This change makes sense to me. |
|
In master now, thanks for your contribution! |
This is a follow-up to #903
This is a second optimization for #882.
TreeItem and Tree have been checking indexes for bounds during indexed access and traversal (
GTK.gtk_tree_model_iter_n_children()) . Such checks are slow as node size computation is an O(N) operation.As Tree already does iteration of O(N) complexity when retrieving a TreeItem by its index, and such iteration detects out-of-bounds problems, preliminary model bounds check is redundant. Also, bounds check is avoidable during iteration over a node - instead of an index, GTK iterator applies directly.
Performance improvement proved by running
org.eclipse.swt.tests.junit.performance.Test_org_eclipse_swt_widgets_Tree.jfaceReveal().In test jfaceReveal[Shape: STAR, virtual: true]:
10_000 elements: 1_523_338_044ns -> 654_307_337ns (-57%)
100_000 elements: 262_129_718_282ns -> 92_328_764_928ns (-65%)
Raw measurements
Timings before the change:Timings after the change: