VTD-XML is just an XML parser, so its encoding is XML.
In next release, VTD-XML will introduce its native encoding which
is XML compatible: XML + VTD .
deferred node expansion will slow down navigation, and when fully
expanded, actually consumes more memory. VTD-XML on the other
hand is fully expanded with its 1.3~1.5x multplying factor. The default
option is used, which may be ( or not be) deferred node expansioin.
----- Original Message -----
From: "Paul Sandoz" <Paul.Sandoz_at_Sun.COM>
To: <users_at_fi.dev.java.net>
Sent: Friday, January 20, 2006 2:13 AM
Subject: Re: Non-FI performance problems
> Jimmy Zhang wrote:
>> VTD-XML and FI can be complementary.
>>
>> The vertical axis is unit-less because it is the multiplying factor and
>> normalized (with the document size being 1). DOM is typically 5x~7x;
>> VTD-XML is 1.3x~1.5x. To VTD-XML, parsing is indexing. XML beans create a
>> lot of object; VTD-XML doesn't. So VTd-Xml
>> should hold the edge both in memory and performance...
>> The best way is to try it...
>>
>
> Do you know if there are any size comparisons comparing the VTD-XML
> document with XML documents?
>
> The memory usage shows how much memory in the JVM is consumed but i would
> be interested in knowing how the actual encoding compared to XML.
>
> In addition do you know what features of DOM were used? i.e. if the
> deferred node expansion feature of Xerces was used. I as understand it
> this can significantly reduce the size of the DOM for large documents
> (before actual traversal and assuming that not all the document needs to
> be traversed). If the deferred node feature is on this makes VTD-XML quite
> impressive in terms of memory usage.
>
> Although it may not be comparing apples-to-apples depending on what APIs
> are actually used. For example if the VTD-XML API was implemented to
> support XML what would be the memory usage? Or if a DOM parser was written
> to optimally support the VTD-XML encoding what would be the memory usage?
> i.e. i think it is useful, if possible, to distinguish between the
> API/implementation and the encoding as this gives a clearer indication of
> the properties of the VTD-XML encoding.
>
> Paul.
>
>> ----- Original Message ----- From: "Mark Swanson"
>> <mark_at_ScheduleWorld.com>
>> To: <users_at_fi.dev.java.net>
>> Sent: Thursday, January 19, 2006 10:58 AM
>> Subject: Re: Non-FI performance problems
>>
>>
>>> Jimmy Zhang wrote:
>>>
>>>> Have you heard of the latest XML processing models called VTD-XML
>>>
>>>
>>> I haven't.
>>> Cursory glance: memory dom vs vtd chart is missing the vertical axis
>>> definition.
>>>
>>> If I understand correctly I think this could complement FI nicely - FI
>>> would handle the transmission and VTD would provide the in-memory random
>>> access document facilities.
>>>
>>> Random access... that's quite an impressive feat - if the charts are
>>> accurate. I find the performance a bit too good to be true considering
>>> that VTD is doing work (indexing) at the same time as reading the stream
>>> while xpp is purely stream reading. I've been through the xpp code and
>>> submitted a fix or two so I'm making more than just a guess at this. I'm
>>> sure this would be explained in the benchmark code.
>>>
>>> Random access... my mind is still thinking of the possibilities.
>>> XmlBeans (or XmL Schema tools like it) might be significantly faster and
>>> memory efficient for a lot of use cases if the XmlObjects didn't have to
>>> actually create objects with attributes. Only get/set methods would be
>>> required. If the random access mechanism was sufficiently fast enough...
>>>
>>> Hopefully I haven't misunderstood the VTD/FI connection. Please correct
>>> me if I misunderstood.
>>>
>>> Cheers.
>>>
>>> --
>>> Free replacement for Exchange and Outlook (Contacts and Calendar)
>>> http://www.ScheduleWorld.com/
>>> WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
>>> WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
>>> VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_fi.dev.java.net
>>> For additional commands, e-mail: users-help_at_fi.dev.java.net
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_fi.dev.java.net
>> For additional commands, e-mail: users-help_at_fi.dev.java.net
>>
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_fi.dev.java.net
> For additional commands, e-mail: users-help_at_fi.dev.java.net
>
>