Saxon » SaxonJS

Interesting. It's not at all clear what could have changes in that regard. The question is really what changed between 2.4 and 2.5, I think. The 2.6 release was very minor.

I will take a look...

Indeed, you are right: version 2.5 already has the same phenomenon and is also noticeably slower than 2.4. We have mentioned version 2.6 because it is the latest version we would like to start using.

I'd rather have non-compliant behavior in this area than a performance hit. Fast id() is essential whereas @xml:id usage is negligible IMO.

To clarify, I'm voting for option #3

I think it's really important to deliver correct results. In this case, correct means taking xml:id into account, even if the browser doesn't. The fact that not doing so produces failing tests in the test suites is an existance proof that some applications may need it.

We already have a mechanism for building caches, they're used to support xsl:key. I tried my hand at extending that model, creating a new index for "id" values (attributes named id or xml:id). That seems to work reasonably well. In the application provided in this issue, performance is back to being on-par with SaxonJS 2.4 after the index is constructed. Constructing the index takes a fraction of a second, not at all noticable if you only do it once (as opposed to doing it between every drag event!)

Bonus feature: I think this will improve "get attribute by ID" performance on Node.js as well because I think that implementation will also benefit from caching. No one has ever noticed that its performance is linear with the size of the document because you don't usually do a lot of lookups unless you're being driven by something like user interaction events.

In the browser, can we please have a solution backed by the native getElementById? It provides a fast primitive and it seems strange to me not to take advantage of it. Any parallel index structures can only be slower.

It seems to me your proposal #3 would combine the best of both worlds?

Note that as a general principle, we NEVER compromise on standards conformance in order to deliver a performance benefit.

Very occasionally we compromise on that principle (an example is stability of collections); when we do so, we generally make it something the user has to explicitly configure.

Combining Martynas' comment 7 with Mike's comment 8, I'm tempted to add a user option to request the browser getElementById behavior. It will be faster and the user can be responsible for knowing whether or not xml:id attributes are relevant.

If automatic fallback from the fast lookup to the compliant lookup is not possible (which is what I thought Norm you were suggesting in option #3), then a config option works for me. Can you let us know how it would look like?

Thanks Norm for your solution. The configuration parameter is a good compromise that allows everyone to enforce the desired behaviour.

Works for me.

Can this come out in 2.7? :) Or how far is 3.x?

If we do a 2.7 release, it will definitely include this fix. The estimate for 3.0 remains essentially unchanged: "as soon as it's ready". We're working hard on it and I hope that it isn't too far away.