- From: Michael Kay <mike@saxonica.com>
- Date: Thu, 14 Mar 2013 09:07:48 +0000
- To: Christian Grün <christian.gruen@gmail.com>
- CC: Adam Retter <adam@exist-db.org>, Florent Georges <fgeorges@fgeorges.org>, EXPath <public-expath@w3.org>
>On the other hand, most XPath functions work with integers, which is why you will usually end up with a 32bit representation of your value anyway. Minor correction: there's nothing intrinsically 32-bit about an XPath integer. >From the implementor’s perspective, I believe it should usually be possible to find memory-saving optimizations for both variants; but it would be interesting to hear more about other implementations. Saxon implements xs:integer (and all its subtypes) using an object that wraps a java long if it fits in a long, or a java BigInteger if not. Sure, there are representations that would be smaller and faster, but I don't think that making savings on the way we handle integers has ever been on anyone's critical path. Of course, for the integer sequence that results from binary-to-octets, we would not materialize the integers eagerly. In Saxon-CE we use java BigDecimal throughout. Makes everything much simpler. Michael Kay Saxonica
Received on Thursday, 14 March 2013 09:08:18 UTC