Thanks, Michael for your answer.
I fully understand that other people are busy too J. I filed a patch improving issue 2. (not 1. as I stated in my last mail) in jira already. Since our application makes heavy use of DOM events and Ranges I believe I understand the events code of xerces quite good by now and we are willing to invest time in improving these areas where feasible. However if I conclude that changing a certain data structure in some way is justified, how is the best way to have this point of view tried by the community (if not by a mail to this list)? Best regards, Ludger From: Michael Glavassevich [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2008 5:12 PM To: [email protected] Subject: RE: Performance hotspot in dispatchEvent... Hi Ludger, DOM Level 2 Events isn't an area I know very well so not something I can't comment on without taking a deeper look (which I haven't had time to do). Please file a JIRA if you have a patch so it doesn't get lost on the mailing list. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] "Ludger Buenger" <[EMAIL PROTECTED]> wrote on 10/02/2008 10:48:58 AM: > 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] -- 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=C2D7127F07.D3A9C>
