Jimmy Zhang wrote:
> 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 .
>
Ah, thanks for putting on me the straight-and-narrow here, I should have
read things more carefully.
> deferred node expansion will slow down navigation, and when fully
> expanded, actually consumes more memory.
Yes.
> 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.
>
OK. At least in Xerces 2.6.x and onwards deferred node expansion is used
by default. Presenting memory results after traversing the DOM may be
useful.
Paul.
> ----- 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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