Elena Litani wrote:
So the docs do not state explicitly that "null" is allowed. But in other
places in XNI, "null" value is also not stated explicitly but could be
used (e.g. while setting a document handler).
So what do you think?
Interesting. I'm quite surprised that 20% of parsing
time (for small documents) is taken up by this. I guess
it's directly related to the number of components in
the parser configuration.
So the docs do not state explicitly that "null" is allowed. But in other
places in XNI, "null" value is also not stated explicitly but could be
used (e.g. while setting a document handler).
This is certainly a possibility but it would require
a change to all components which is not too bad for
Xerces but what about other people's components? So
this would be a breaking change.
Just in case you are wondering what are other solutions are:
1) each component could implement setFeature, setProperty and get all
the properties and features. However, during
XMLComponent.reset() no features and properties will be queried.
I am not sure if XNI components were designed to be reset in such a way,
and I suspect this approach might be a bit slower.
I'm not quite following your explanation. Are you
saying that each component would still be passed the
component manager but that the component is smart
enough to *not* query the settings that it got from
the last parse? This seems fragile at best.
2) introduce a new internal feature, e.g.
"/internal/settings-unchanged", that
each component can query before querying the rest of features and
properties. If this new feature is set to true, the component won't
query any other features. Again this is a bit slower, plus we are
introducing yet one more feature to Xerces..
I think that this would be the safest change that
would allow existing components to continue to work.
However, it makes me wonder about how well this
would actually work in practice. Would this apply
to *all* features and properties? or only internal?
only external?
The more dynamic the internals, the more likely
that some setting has changed. Then this special
internal marker feature becomes useless and actually
*adds* work because each component would need to
query this feature and then still need to query
all the other ones.
And when you look at it, this is no different than
passing a null component manager. Unless absolutely
no setting changed, you would *not* be able to pass
a null reference.
Perhaps we need to look for performance gains in
other places...
--
Andy Clark * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
