You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Ludger Buenger <lu...@realobjects.com> on 2008/09/26 17:26:46 UTC
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
RE: Performance hotspot in dispatchEvent...
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Ludger,
"Ludger Buenger" <lu...@realobjects.com> wrote on 10/02/2008
11:49:00 AM:
> Thanks, Michael for your answer.
>
> I fully understand that other people are busy too.
>
> I filed a patch improving issue 2. (not 1. as I stated in my last
> mail) in jira already.
Thanks.
> 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.
I'm sure you have a much better handle on it than me, both from a spec and
implementation perspective.
> 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)?
The mailing list is the best place though it may take some time for us to
give feedback. With the turnover in the development community since the
project first started some parts of Xerces really have no expert anymore;
mostly those which have been stable for so long that they rarely have a
need to be updated. The Events and Ranges part of DOM Level 2 is
unfortunately one of those. I've fixed some obvious bugs in that code over
the years but haven't ever looked at it in depth (or read much of the
spec).
By the way, I'm still working my way through your WeakReference patches.
Hope to have all of those in for the next release (whenever we decide to
have that).
> Best regards,
>
> Ludger
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
RE: Performance hotspot in dispatchEvent...
Posted by Ludger Buenger <lu...@realobjects.com>.
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:mrglavas@ca.ibm.com]
Sent: Thursday, October 02, 2008 5:12 PM
To: j-dev@xerces.apache.org
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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
"Ludger Buenger" <lu...@realobjects.com> 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: j-dev@xerces.apache.org
> > 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: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
--
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>
RE: Performance hotspot in dispatchEvent...
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
... 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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Michael Glavassevich/Toronto/IBM@IBMCA 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: mrglavas@ca.ibm.com
> E-mail: mrglavas@apache.org
>
> "Ludger Buenger" <lu...@realobjects.com> 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: j-dev@xerces.apache.org
> > > 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: j-dev-unsubscribe@xerces.apache.org
> > For additional commands, e-mail: j-dev-help@xerces.apache.org
RE: Performance hotspot in dispatchEvent...
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
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: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
"Ludger Buenger" <lu...@realobjects.com> 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: j-dev@xerces.apache.org
> > 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: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
RE: Performance hotspot in dispatchEvent...
Posted by Ludger Buenger <lu...@realobjects.com>.
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: j-dev@xerces.apache.org
> 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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org