> Yes, but I don't know if it will ultimately work.
Why?
The component manager (parser configuration in the case of Xerces) knows
when anything changes (features, properties, pipeline). So it knows whether
anything needs to be reset or not. If no features/properties have been
modified the configuration does not need to pass component manager to the
components in the pipeline
While this change would require us to change our internal implementation, I
would like to understand if this change will effect any of the XNI
developers.
Does anyone other than us (Andy and Xerces developers) created any new XNI
components and added those to the parsing pipeline? And if so, does the new
component reset() method relies on the fact the component manager is never
null?
If people have written components, when we can use 3rd option: introduce a
special feature that can only be set by the component manager and will have
a meaning "no features or properties were modified in between 2 parsers".
The component implementation can improve performance by querying this
feature first and if nothing was changed no other features or properties
will be queried.
Thank you,
--
Elena Litani/ IBM Toronto
Monday, October 27, 2003 7:43 PM
To: [EMAIL PROTECTED]
cc:
From: Andy Clark <[EMAIL PROTECTED]>
Subject: Re: XNI performance: resetting the pipeline
Arnaud Le Hors wrote:
> Andy, this last recommendation is at odd with your first statement.
> I agree we should look for performance gains in other places. But we
> should do that too, not instead. 20% is such a large number that we
> ought to address this first.
I think I stated it poorly. What I meant was that
I don't think we can change this safely, as per the
concerns I detailed in my other posts. Therefore, I
think we're going to end up having to improve other
areas in other to make up the lost performance.
> I personally like Elena's first proposal, to pass null. I think it's
> simple and while I agree it *may* cause some disruption the gain is such
> that it makes it worthwhile. Think about the number of people/users who
> will benefit from it vs the number of component developers who will have
> to update their components...
Yes, but I don't know if it will ultimately work.
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
