Community
Participate
Working Groups
it calls isChildOf which in turn equals on lists - and that's expensive because it allocates a lot of iterator objects attached is the allocation trace of java.util.AbstractList$ListItr after a single click in the workbench
Created attachment 2503 [details] allocation trace
actually i think now that isChildOf is the culprit it should be optimized for memory consumption - it's called very often its code now: public boolean isChildOf(KeySequence keySequence) { return keyStrokes.size() > keySequence.keyStrokes.size() && keyStrokes.subList(0, keySequence.keyStrokes.size ()).equals(keySequence.keyStrokes); } this allocates new objects in subList() and in equals() little recoding here will save a lot of garbage objects
another one is: org.eclipse.ui.internal.actions.keybindings.Path.equalsOrIsChildOf but it's called less often so it's less of a problem
this definitely will be recoded. as well, i think there are a few calls in there (compare/equals) that compare lists by instantiating iterators first instead of for(;;) over them. this is a cause of unnecessary object creation as well.
yes, this class is used so often that it should really be tuned the methos isChildOf is called an amazing number of times - any speedup there will help. eliminating the combination of sublist/equals and replacing with a simple iteration over elements would be a good start
fixed. all compare, equals, isChildOf, and equalsOrIsChildOf methods have been optimized. No new objects should be allocated during these methods. Execution time should further improve due to minor algorithm changes as well.
