Community
Participate
Working Groups
200405200010 The commands API calls IActivityManager.getIdentifier() with every focus change to determine whether a given command is active. This is expensive - if the identifier doesn't exist, then it is created and its patterns are calculated. It would be better if the CommandCallback kept a handle on an IIdentifier instead of requesting a new one every time. See CommandCallback.isActive()
Waiting for a clear performance test case.
Hey Doug, can you attach the patch you made?
After looking at the activities implementation it became apparent that we weren't using WeakHashMaps correctly. We were inserting identifier->object into them, where object contained a non-weak reference to the identifier. This ensured that the objects were never being released. HOWEVER... After correcting the logic by ensuring that we wrapped the object in a weak reference itself prior to insertion into the map our performance tanked out. I wrote a test that would iterate some number of times(200,400, and 1000) and get 50 different identifier objects for each iteration. For every 10th iteration of the outer loop I would call System.gc(). I did these tests against our current implementation, the "fixed" implementation with both our regular activity set and a bloated activity set containing 104 patterns. It was the case that the generated identifiers would never match any of the patterns, meaning that each pattern binding would have to be evaluated in order to determine if the identifier was disabled or not. The results were as follows(I hope this pretty formats): Iterations 200 400 1000 Time (ms) Usage Aloc (b) Time (ms) Usage Aloc (b) Time (ms) Usage Aloc (b) w activity bloat w weak identifiers 18312 211392 35718 357504 89656 357169 w current implmentation 4093 -234600 7606 3264 19453 72376 w standard activities w weak identifiers 4328 391120 8219 511976 20188 511976 w current implmentation 4063 -21640 7719 63832 19015 72376 With a corrected implementation both memory and execution time increase substantially. The speed was expected but the memory was a surprise. I suspect that it was caused by re-evaluation of Pattern objects with every Identifier creation. In short, this is one bug we probably shouldn't fix.
