[
Lists Home |
Date Index |
Thread Index
]
Elliotte Harold wrote:
> Rich Salz wrote:
>
>
>> Yes, right now, it is probably not a performance issue that a streaming
>> parser has to buffer everything until it sees the ">". That can only be
>> addressed by anecdotal evidence. What is more important is that
>> *architecturally* this is a bottleneck. As things get faster, all the
>> other implementations (ew, a JVM? :) will fall away, and we'll still be
>> left with this architectural problem. I betcha it's already an issue
>> for
>> some folks building XML parsers in hardware.
>
>
> I don't believe that for a minute. As hardware gets faster, this will
> too. As the VM and just in time compilers get better, this will too.
> Other algorithms may get faster here and there, but they're not going
> to zero. Unless someone has really good measurements to prove caching
> attributes is a problem, I don't believe it.
>
> You say, "I betcha it's already an issue for some folks building XML
> parsers in hardware." Datapower builds XML parsers in hardware. Are
> you saying this is an issue for you? If so, please elaborate. If not,
> why do you think it would be an issue?
>
You are not asking somebody to give out company secrets, are you :-)
The argument was about namespaces in XML.
>The fact that namespaces in XML requires you to parse all attributes before you can report the name of the start tag even in streaming implementations adds a significant perf cost.
>
Performance is nothing to worry about.
But the possibility to define, redefine, even UNDEFINE namespace scopes
in every single XML element is a bit baroque.
I think those few applications that need to nest documents from
namespaces unknown in advance could have dealt pretty well with
<{ns}:lname/> and all others could have happily declared their
namespaces in the root elemen.
Anyway, (sigh) the milk is already on the floor.
cheers,
Burak
|
