No answer is also an answer. Thus I will file an issue in jira regarding my patch for issue 1) and silently ignore issue 2) without investing any time... if this is of interest for anybody at all?
> -----Original Message----- > From: Ludger Buenger > Sent: Friday, September 26, 2008 5:27 PM > To: [email protected] > Subject: Performance hotspot in dispatchEvent... > > > Hello Community, > > I have an issue I's like to discuss with the community before I place > suggestions in the jira system. > > In our heavily event-driven application I discovered that quite a > significant amount of time is consumed inside the xerces event > dispatching system (see attached screenshot) > > As you can see, over 40% of the overall application time is consumed > inside xerces event dispatchal outside of our code. Obviously this > needs me to evaluate ways to reduce using the event system however this > clearly shows optimization potential inside xerces. > > It seems to me that xerces doesn't scale well for large numbers of > different event listener types registered upon several nodes. > > But where inside xerces the processing time is lost? > 1) 25% is consumed for cloning node listener lists (in line 740, 769 > and 802 of DocumentImpl, 542096) > 2) 18% is consumed for checking whether a specific listener is still > registered (line 746, 775, 809 of same file) > > > Regarding 2): > > To improve the behavior of the second hotspot, I suggest to add a > boolean flag to the LEntry class permitting a constant time boolean > check whether an LEntry instance has been removed from the listener > datastructure instead of calling an expensive contains()-operation > which requires time linear to the number of listeners for a given node. > However since I am not too familiar with serialization problems. > As far as I understood serialization, we can keep this flag transient > since it will always be false while any instance of LEntry is inside > the event listener data structure. If an LEntry is removed from the > event listener data structure this flag will be changed to true but > when removed any LEntry instance will never be serialized. > > Am I correct? > > This suggestion together with a small change unifying the event > dispatchal code to a single method instead of maintaining similar code > with minimal changes three times can be found in the patch attached for > inspection. > > > Regarding 1): > Improving the performance footprint regarding cloning node listeners is > far more difficult since I imagine different ways how this can be done > - not to mention those others might come up with. > > The most point that needs decision before I can place any suggestions > is whether we can/should change the data structure currently storing > event listeners due to implications upon serializability. > > A simple analysis shows that the event listener data structures are > already *broken* after serialization/deserialization: > > The LCount class keeping track of the current number of event listener > types is static/global I'd be happy to provide a suggestion) and thus > will always contain corrupt data after deserializing a Dom having event > listeners registered serialized by a different VM! > > > So my question is: is there a good reason why event listeners are > serialized together with the Dom and not transient? > > Since serialization for event listeners is broken anyhow shouldn't we > use this opportunity to make the eventListeners Hashtable in > DocumentImpl transient so that we can perform arbitrary changes the > eventlistener data structure without worrying about serialization? > > I do not see any good use case why event listeners should survive > serialization and it's broken anyhow. > > > > I'd be willing to commit some time to provide suggestions to > a) improve performance footprint for the event listener data structure > b) change the currently global LCount class to make it local per DOM > (which also would have other advantages, e.g. making event listener > registration thread-safe across different DOM instances which it > currently is not!). > > However I need to know how the community feels whether this would be ok. > And making the event listener data structure transient feels the right > thing to do to me. > > Any Comments? Suggestions? Flames? > > > Best regards, > > Ludger Bünger > > > > [1] attached screenshot from profiler session: > xercesEventsProfilingSession.jpg [2] attached patch: > xercesDocumentImplEventListenerRemovalCheckPatch.txt > > > -- > Dipl.-Inf. Ludger Bünger > > -- > This message was scanned by ESVA and is believed to be clean. > Click here to report this message as spam. > http://mailfilter.nc-sb.de/cgi-bin/learn-msg.cgi?id=BCD6A27B94.A841D > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
