... so not something I can't comment on ... --> ... so not something I can comment on ...
Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] Michael Glavassevich/Toronto/[EMAIL PROTECTED] wrote on 10/02/2008 11:11:34 AM: > 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]
