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