Performance stymied by UIElement_CreateAutomationPeer
-
Hey, I've been optimising a piece of software with a very large number of simple controls (~30000), most of whom have their parent panel virtualised at any one time (reducing the number in the visual tree to a few hundred). Running through ANTS profiler, I'm told that 60-70% of CPU-time is taken up by UIElement_CreateAutomationPeerDelegate.Invoke and its child methods. A user interacting with the program for 20 seconds or so [creating an additional ~20 of these controls, deleting a few, and moving a few around the page] results in this method being called 5.4 million times. Putting a counter near this method confirms this when run without debugging/ANTS. As far as I'm aware, I haven't touched AutomationPeer-related methods, and it is used for Accessibility/COM stuff. Can I turn this 'function' off, or are there ways of reducing how many times it is called? TIA, Lee
-
Hey, I've been optimising a piece of software with a very large number of simple controls (~30000), most of whom have their parent panel virtualised at any one time (reducing the number in the visual tree to a few hundred). Running through ANTS profiler, I'm told that 60-70% of CPU-time is taken up by UIElement_CreateAutomationPeerDelegate.Invoke and its child methods. A user interacting with the program for 20 seconds or so [creating an additional ~20 of these controls, deleting a few, and moving a few around the page] results in this method being called 5.4 million times. Putting a counter near this method confirms this when run without debugging/ANTS. As far as I'm aware, I haven't touched AutomationPeer-related methods, and it is used for Accessibility/COM stuff. Can I turn this 'function' off, or are there ways of reducing how many times it is called? TIA, Lee
At the risk of getting 1'ed, I'd say you are trying to band aid things here. Fix the real issue. You shouldn't need 30,000 controls in a single window :). -- Modified Monday, July 18, 2011 7:04 PM
-
At the risk of getting 1'ed, I'd say you are trying to band aid things here. Fix the real issue. You shouldn't need 30,000 controls in a single window :). -- Modified Monday, July 18, 2011 7:04 PM
Haha, well agreed to an extent. The maximum number of controls 'on' the window at any one time is actually around 200 (and usually only around 40) - the rest are held in memory waiting to be connected to the visual tree when scrolling takes place. I have tried virtualising these 'properly' so that they are re-used but the overhead for them binding to their data is actually more costly than having them just sit in memory (which I certainly found surprising)