[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] XML Schema: "Best used with the ______ tool"
- From: "Michael Kay" <mike@saxonica.com>
- To: "'Boris Kolpackov'" <boris@codesynthesis.com>
- Date: Fri, 28 Nov 2008 15:29:23 -0000
In the example I mentioned
> in my previous email, even if the XSLT/XQuery processor can
> figure out at the query compile time (based on the schema
> information) that the 'people' element can only contain the
> 'person' element and skip the element name check (I don't
> know if there are any production implementations that do
> this), you will presumably still need a map lookup to get to
> the "age" attribute.
> I don't think this can be anywhere close to a single direct
> memory access in case of data binding.
I think you'll find it's close enough. As far as Saxon is concerned, I put
further optimization of this kind of thing (for example, allocating required
attributes to fixed positions and accessing them by direct offset) on the
back burner some years ago because profiling showed that the serial search
for an attribute simply wasn't showing up on the radar. It could be done if
it was necessary, but it's not necessary.
>
>
> I agree with Dennis here in that XQuery can be usable when
> you need to access a small subset of an XML document.
> However, when one needs to access most of the data, or,
> worse, access the same data many times, data binding will
> have speed/memory advantage.
Evidence please! I don't see any reason why it should.
(There are still people who maintain that coding in assembler is faster than
in C, or that coding in C is faster than in Java. All the evidence is that
there are very few people with the skills in the lower-level language to
beat the optimizers for the higher-level language. It can be done if you try
hard enough, but not by the average programmer.)
>
> Then there is the whole aspect of interfacing with the rest
> of the world. Assembling text queries from bits and pieces
> that come from different sources and then unpacking the
> results for further processing does not sound like something
> that is easy to use.
>
Sounds a lot easier than coding it in Java.
Michael Kay
http://www.saxonica.com/
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]