Alan Hudson wrote:
> sandoz_at_dev.java.net wrote:
>
>
>>User: sandoz
>>Date: 2005/03/01 07:09:06
>>
>>Log:
>>Fixed bug for incorrect setting of _octetBufferStart when the octet
>>buffer is resized.
>>Fully implemented conformant UTF-8 decoding. Fixed bug for the UTF-8
>>encoding for characters encoded in two bytes.
>>Added preliminary support for UTF-8 decoding with NCName character
>>validation.
>>
>>
>>
>
> that fixed the issue for me.
>
Good.
> An interesting datapoint. If I start the _octetBuffer at 1024 then
> parsing that 20 meg file takes 1922 ms, if I start with a really large
> size(around 20 megs) then it takes 1547 ms. The odd datapoint is if I
> size the array perfectly(no reallocs) for that datafile, 420K, then it
> parses at 1750 ms.
>
Odd indeed.
> I think having application control of an initial size would be useful.
> X3D will likely encounter some pretty bug files so we'd likely give it a
> pretty large buffer to begin with... unless its our mobile version
> which we then would give it a smaller starting value.
>
We can have generic property (that can be used for SAX, StAX and DOM):
http://jvnet.org/fastinfoset/decode/octet-buffer-size
that takes an instance of Integer.
Want to modify the code? :-), if you do so for SAX then i can make the
changes for StAX and DOM.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109