Menu
▾
▴
vtd-xml-users
|
From: Jimmy Z. <cra...@co...> - 2006-11-30 08:49:31
|
RE: [Vtd-xml-users] Performance in comparison to libxml2looping thru the = test a number of time is certainly going to help the accurracy of the = test, especailly for Java... reading everything in memory to eliminate variations due to I/O also = helps... Creating string is where this gets subtle and interesting ... but = shouldn't matter a whole lot... we are going to publish benchmark numbers and code on XML content = changes comparing DOM with VTD-XML... the comparison, simply put, will be shocking, VTD-XML outperforms DOM by = 15~25 times :-) ----- Original Message -----=20 From: John Kraal=20 To: Jimmy Zhang=20 Sent: Thursday, November 30, 2006 12:34 AM Subject: RE: [Vtd-xml-users] Performance in comparison to libxml2 Jimmy, I ran the tests multiple times to include startup and shutdown = processing. I could create a loop doing 50 to 100 tests if that's what = you prefer (or like to see). Creating strings is the actual retrieving of node data; looks quite = important to me.. -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...] Sent: Thu 30-11-2006 4:22 To: John Kraal Cc: vtd...@li... Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 Benchmarks usualy iterate the test for a large numbers before taking = the average for each iteration, this is especially important for Java because = server JVM takes some iterations to warm up ... Also Is there a need for creating strings?? A smart work around may = exist to completely bypass this stage... ----- Original Message ----- From: "John Kraal" <jk...@in...> To: "Jimmy Zhang" <cra...@co...> Sent: Tuesday, November 28, 2006 11:48 PM Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 > In order > > * I used 1.8; but indeed I should've tested the java-cvs as well. > * Test code included; jkl.files.xml is described somewhat earlier = (137 > mb) and the other attached as well. > * Java 1.5 something, it's a pain to get that installed and = uninstalled > on Debian (Debian mindset: Proprietary software is evil) > * Parsing is actually reading the file and making it workable; maybe > that just didn't change significantly? > * I really cannot explain.. I believe it is now about the same speed = as > '//*' > > Jimmy Zhang wrote: >> looks interesting.. a few things >> >> * you should check out the latest java version for the testing as = well >> since there has been changes >> * What are the test code and conditions? We are doing a bit of >> benchmarking >> ourselves, mostly with modest file sizes... >> >> * for java version ,did you use server JVM, that makes a hell of >> difference?? >> >> I read it a bit more, there are more questions than answers... >> * from vtd-xml-c to vtdxml 1.8 cvs, there is no change at all >> at the parsing code, why there is a big difference in performance? >> >> * how come //*[local-name()=3D"Descriptor"] takes shorter amoutn >> of time than //* >> ----- Original Message ----- From: "John Kraal" <jk...@in...> >> To: "Jimmy Zhang" <cra...@co...> >> Sent: Tuesday, November 28, 2006 4:38 AM >> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >> >> >>> I've tested the CVS version and included the results I've recorded = until >>> now. I'm actually a bit too lazy to build other java-parsers to = test >>> with, but it indicates a little of the C performance. >>> >>> I'm interested in your opinion on this before continuing with = testing.. >>> >>> Regards, >>> John >>> >>> Jimmy Zhang wrote: >>>> There has been some significant XPath eval performance = enhancement >>>> slated >>>> for next release, if you want to give a try, it is also in CVS = moments >>>> ago... >>>> ----- Original Message ----- From: "John Kraal" = <jk...@in...> >>>> To: "Jimmy Zhang" <cra...@co...> >>>> Sent: Tuesday, November 21, 2006 12:38 AM >>>> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >>>> >>>> >>>>> What failed exactly? Anyway, I'll do what I can; just notify me = when >>>>> you >>>>> release 1.8. >>>>> >>>>> regards, >>>>> John >>>>> >>>>> Jimmy Zhang wrote: >>>>>> John, I wasn't able to get the toolchain script to work? >>>>>> Can you help us create another tar.gz release after the release = of >>>>>> 1.8 >>>>>> in a few days.. >>>>>> Jimmy >>>>>> ----- Original Message ----- From: "John Kraal" = <jk...@in...> >>>>>> To: "Jimmy Zhang" <cra...@co...> >>>>>> Cc: <vtd...@li...> >>>>>> Sent: Tuesday, November 07, 2006 12:12 AM >>>>>> Subject: Re: [Vtd-xml-users] Performance in comparison to = libxml2 >>>>>> >>>>>> >>>>>>> No, I'm sorry - the files I used to test contains data from my >>>>>>> employer; >>>>>>> I will not be the one to distribute that :-). But it's quite = easy to >>>>>>> create a fairly simple xml file like mine; and test it. >>>>>>> >>>>>>> Remember that I'm not testing a Java application, but merely = C. >>>>>>> >>>>>>> The sources are in the previous email. >>>>>>> >>>>>>> The structure is quite simple, and as I'm not able to create a = XSD >>>>>>> schema from a XML File easily (not really sure with what), = here the >>>>>>> structure at it's simplest, just add some elements: >>>>>>> >>>>>>> <shipments> >>>>>>> <shipment dosvlg=3D"123" afd=3D"abc123"> >>>>>>> <from>NLAMS</from> >>>>>>> <to>NLRTM</to> >>>>>>> <goods> >>>>>>> <goodsline> >>>>>>> <merknr>abc</merknr> >>>>>>> <col code=3D"pl">12345</col> >>>>>>> </goodsline> >>>>>>> </goods> >>>>>>> <relations> >>>>>>> <relation srtnaw=3D"123" tsroln=3D"123" relnr=3D"123" = zoek=3D"abc"> >>>>>>> <tsnam1>abc</tsnam1> >>>>>>> <coordinates> >>>>>>> <tscoox>-12.3456</tscoox> >>>>>>> <tscooy>-12.3456</tscoox> >>>>>>> </coordinates> >>>>>>> </relation> >>>>>>> </relations> >>>>>>> </shipment> >>>>>>> </shipments> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jimmy Zhang wrote: >>>>>>>> Can you provide a few sample XML files that you used for the >>>>>>>> testing? >>>>>>>> >>>>>>>> I am sure there can be additioal performance tuning for = performance >>>>>>>> evaluation... >>>>>>>> >>>>>>>> So far the response we got compare VTD-XML favorably with = Xerces... >>>>>>>> for the java version.. >>>>>>>> ----- Original Message ----- From: "John Kraal - Kewill >>>>>>>> Interchain NL" >>>>>>>> <jk...@in...> >>>>>>>> To: <vtd...@li...> >>>>>>>> Sent: Monday, November 06, 2006 4:23 AM >>>>>>>> Subject: [Vtd-xml-users] Performance in comparison to libxml2 >>>>>>>> >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I've been playing with vtdxml for a while now, and my latest >>>>>>>>> experience >>>>>>>>> is not very encouraging to go on :(... >>>>>>>>> >>>>>>>>> I have created a file with _lots_ of recurring structures = and >>>>>>>>> amounts of >>>>>>>>> recurring data (about 137 MB), eventually I created a xpath = to >>>>>>>>> select >>>>>>>>> the name of every relation in the 4th role (doesn't really >>>>>>>>> matter). >>>>>>>>> >>>>>>>>> So, I executed it, with the code included for vtdxml (see >>>>>>>>> vtdxml.c), >>>>>>>>> and >>>>>>>>> it performed like this: >>>>>>>>> >>>>>>>>> unims@gxvm1:~/src/xmltest$ time ./test ./jkl.files.xml >>>>>>>>> '//relation[@tsroln=3D04]/tsnam1' >> /dev/null >>>>>>>>> >>>>>>>>> real 0m4.940s >>>>>>>>> user 0m4.625s >>>>>>>>> sys 0m0.256s >>>>>>>>> >>>>>>>>> With 162450 bytes of terminal output. >>>>>>>>> >>>>>>>>> Then, the horrible thing happened, I used lixml2 with an = adjusted >>>>>>>>> reference xpath-program. (xpath1.c from their website, only = with >>>>>>>>> content >>>>>>>>> retrieval): >>>>>>>>> >>>>>>>>> unims@gxvm1:~/src/libxmltest$ time ./test ./jkl.files.xml >>>>>>>>> '//relation[@tsroln=3D04]/tsnam1' >> /dev/null >>>>>>>>> >>>>>>>>> real 0m2.545s >>>>>>>>> user 0m2.201s >>>>>>>>> sys 0m0.321s >>>>>>>>> >>>>>>>>> The size of the output was 150808 bytes. >>>>>>>>> >>>>>>>>> This is an incredible difference, am I doing something = wrong? Or >>>>>>>>> did I >>>>>>>>> have too many expectations of vtd? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> John Kraal >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> = -------------------------------------------------------------------------= ------- >>>>>>>>\ >>>>>>>>> = -------------------------------------------------------------------------= >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Using Tomcat but need to do more? Need to support web = services, >>>>>>>>> security? >>>>>>>>> Get stuff done quickly with pre-integrated technology to = make your >>>>>>>>> job >>>>>>>>> easier >>>>>>>>> Download IBM WebSphere Application Server v.1.0.1 based on = Apache >>>>>>>>> Geronimo >>>>>>>>> = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> = -------------------------------------------------------------------------= ------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Vtd-xml-users mailing list >>>>>>>>> Vtd...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> =3D >>>>>>> >>>>>>=20 |
|
From: Jimmy Z. <cra...@co...> - 2006-12-05 01:04:44
|
RE: [Vtd-xml-users] Performance in comparison to libxml2latest = benchmarks http://vtd-xml.sf.net/benchmark.html ----- Original Message -----=20 From: John Kraal=20 To: Jimmy Zhang=20 Sent: Thursday, November 30, 2006 12:34 AM Subject: RE: [Vtd-xml-users] Performance in comparison to libxml2 Jimmy, I ran the tests multiple times to include startup and shutdown = processing. I could create a loop doing 50 to 100 tests if that's what = you prefer (or like to see). Creating strings is the actual retrieving of node data; looks quite = important to me.. -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...] Sent: Thu 30-11-2006 4:22 To: John Kraal Cc: vtd...@li... Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 Benchmarks usualy iterate the test for a large numbers before taking = the average for each iteration, this is especially important for Java because = server JVM takes some iterations to warm up ... Also Is there a need for creating strings?? A smart work around may = exist to completely bypass this stage... ----- Original Message ----- From: "John Kraal" <jk...@in...> To: "Jimmy Zhang" <cra...@co...> Sent: Tuesday, November 28, 2006 11:48 PM Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 > In order > > * I used 1.8; but indeed I should've tested the java-cvs as well. > * Test code included; jkl.files.xml is described somewhat earlier = (137 > mb) and the other attached as well. > * Java 1.5 something, it's a pain to get that installed and = uninstalled > on Debian (Debian mindset: Proprietary software is evil) > * Parsing is actually reading the file and making it workable; maybe > that just didn't change significantly? > * I really cannot explain.. I believe it is now about the same speed = as > '//*' > > Jimmy Zhang wrote: >> looks interesting.. a few things >> >> * you should check out the latest java version for the testing as = well >> since there has been changes >> * What are the test code and conditions? We are doing a bit of >> benchmarking >> ourselves, mostly with modest file sizes... >> >> * for java version ,did you use server JVM, that makes a hell of >> difference?? >> >> I read it a bit more, there are more questions than answers... >> * from vtd-xml-c to vtdxml 1.8 cvs, there is no change at all >> at the parsing code, why there is a big difference in performance? >> >> * how come //*[local-name()=3D"Descriptor"] takes shorter amoutn >> of time than //* >> ----- Original Message ----- From: "John Kraal" <jk...@in...> >> To: "Jimmy Zhang" <cra...@co...> >> Sent: Tuesday, November 28, 2006 4:38 AM >> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >> >> >>> I've tested the CVS version and included the results I've recorded = until >>> now. I'm actually a bit too lazy to build other java-parsers to = test >>> with, but it indicates a little of the C performance. >>> >>> I'm interested in your opinion on this before continuing with = testing.. >>> >>> Regards, >>> John >>> >>> Jimmy Zhang wrote: >>>> There has been some significant XPath eval performance = enhancement >>>> slated >>>> for next release, if you want to give a try, it is also in CVS = moments >>>> ago... >>>> ----- Original Message ----- From: "John Kraal" = <jk...@in...> >>>> To: "Jimmy Zhang" <cra...@co...> >>>> Sent: Tuesday, November 21, 2006 12:38 AM >>>> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >>>> >>>> >>>>> What failed exactly? Anyway, I'll do what I can; just notify me = when >>>>> you >>>>> release 1.8. >>>>> >>>>> regards, >>>>> John >>>>> >>>>> Jimmy Zhang wrote: >>>>>> John, I wasn't able to get the toolchain script to work? >>>>>> Can you help us create another tar.gz release after the release = of >>>>>> 1.8 >>>>>> in a few days.. >>>>>> Jimmy >>>>>> ----- Original Message ----- From: "John Kraal" = <jk...@in...> >>>>>> To: "Jimmy Zhang" <cra...@co...> >>>>>> Cc: <vtd...@li...> >>>>>> Sent: Tuesday, November 07, 2006 12:12 AM >>>>>> Subject: Re: [Vtd-xml-users] Performance in comparison to = libxml2 >>>>>> >>>>>> >>>>>>> No, I'm sorry - the files I used to test contains data from my >>>>>>> employer; >>>>>>> I will not be the one to distribute that :-). But it's quite = easy to >>>>>>> create a fairly simple xml file like mine; and test it. >>>>>>> >>>>>>> Remember that I'm not testing a Java application, but merely = C. >>>>>>> >>>>>>> The sources are in the previous email. >>>>>>> >>>>>>> The structure is quite simple, and as I'm not able to create a = XSD >>>>>>> schema from a XML File easily (not really sure with what), = here the >>>>>>> structure at it's simplest, just add some elements: >>>>>>> >>>>>>> <shipments> >>>>>>> <shipment dosvlg=3D"123" afd=3D"abc123"> >>>>>>> <from>NLAMS</from> >>>>>>> <to>NLRTM</to> >>>>>>> <goods> >>>>>>> <goodsline> >>>>>>> <merknr>abc</merknr> >>>>>>> <col code=3D"pl">12345</col> >>>>>>> </goodsline> >>>>>>> </goods> >>>>>>> <relations> >>>>>>> <relation srtnaw=3D"123" tsroln=3D"123" relnr=3D"123" = zoek=3D"abc"> >>>>>>> <tsnam1>abc</tsnam1> >>>>>>> <coordinates> >>>>>>> <tscoox>-12.3456</tscoox> >>>>>>> <tscooy>-12.3456</tscoox> >>>>>>> </coordinates> >>>>>>> </relation> >>>>>>> </relations> >>>>>>> </shipment> >>>>>>> </shipments> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jimmy Zhang wrote: >>>>>>>> Can you provide a few sample XML files that you used for the >>>>>>>> testing? >>>>>>>> >>>>>>>> I am sure there can be additioal performance tuning for = performance >>>>>>>> evaluation... >>>>>>>> >>>>>>>> So far the response we got compare VTD-XML favorably with = Xerces... >>>>>>>> for the java version.. >>>>>>>> ----- Original Message ----- From: "John Kraal - Kewill >>>>>>>> Interchain NL" >>>>>>>> <jk...@in...> >>>>>>>> To: <vtd...@li...> >>>>>>>> Sent: Monday, November 06, 2006 4:23 AM >>>>>>>> Subject: [Vtd-xml-users] Performance in comparison to libxml2 >>>>>>>> >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I've been playing with vtdxml for a while now, and my latest >>>>>>>>> experience >>>>>>>>> is not very encouraging to go on :(... >>>>>>>>> >>>>>>>>> I have created a file with _lots_ of recurring structures = and >>>>>>>>> amounts of >>>>>>>>> recurring data (about 137 MB), eventually I created a xpath = to >>>>>>>>> select >>>>>>>>> the name of every relation in the 4th role (doesn't really >>>>>>>>> matter). >>>>>>>>> >>>>>>>>> So, I executed it, with the code included for vtdxml (see >>>>>>>>> vtdxml.c), >>>>>>>>> and >>>>>>>>> it performed like this: >>>>>>>>> >>>>>>>>> unims@gxvm1:~/src/xmltest$ time ./test ./jkl.files.xml >>>>>>>>> '//relation[@tsroln=3D04]/tsnam1' >> /dev/null >>>>>>>>> >>>>>>>>> real 0m4.940s >>>>>>>>> user 0m4.625s >>>>>>>>> sys 0m0.256s >>>>>>>>> >>>>>>>>> With 162450 bytes of terminal output. >>>>>>>>> >>>>>>>>> Then, the horrible thing happened, I used lixml2 with an = adjusted >>>>>>>>> reference xpath-program. (xpath1.c from their website, only = with >>>>>>>>> content >>>>>>>>> retrieval): >>>>>>>>> >>>>>>>>> unims@gxvm1:~/src/libxmltest$ time ./test ./jkl.files.xml >>>>>>>>> '//relation[@tsroln=3D04]/tsnam1' >> /dev/null >>>>>>>>> >>>>>>>>> real 0m2.545s >>>>>>>>> user 0m2.201s >>>>>>>>> sys 0m0.321s >>>>>>>>> >>>>>>>>> The size of the output was 150808 bytes. >>>>>>>>> >>>>>>>>> This is an incredible difference, am I doing something = wrong? Or >>>>>>>>> did I >>>>>>>>> have too many expectations of vtd? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> John Kraal >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> = -------------------------------------------------------------------------= ------- >>>>>>>>\ >>>>>>>>> = -------------------------------------------------------------------------= >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Using Tomcat but need to do more? Need to support web = services, >>>>>>>>> security? >>>>>>>>> Get stuff done quickly with pre-integrated technology to = make your >>>>>>>>> job >>>>>>>>> easier >>>>>>>>> Download IBM WebSphere Application Server v.1.0.1 based on = Apache >>>>>>>>> Geronimo >>>>>>>>> = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> = -------------------------------------------------------------------------= ------- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Vtd-xml-users mailing list >>>>>>>>> Vtd...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> =3D >>>>>>> >>>>>>=20 |
|
From: Mark S. <ma...@Sc...> - 2006-12-05 03:00:11
|
Jimmy Zhang wrote: > latest benchmarks > > http://vtd-xml.sf.net/benchmark.html Very impressive, as usual. I do have a concern/question: what is the overhead of XPath parsing in these cases vs coding the queries in Java using the VTDNav class? I think I remember you posting before that the overhead was negligible, but I wasn't sure in what context or what circumstances this was the case. If you have any additional comments in this regard I'd appreciate reading them. In particular, if you had any performance tips using the XPath evaluator that would be great. Also, I have just found out about XMLModifier. Do you have any example code that shows how best to use this class? Not that it looks difficult - I'm just incredibly lazy and just want to copy/paste code that sets up the VTDNav and calls bind() appropriately. :-) I couldn't find a way to create a masterDocument with a specific character set or other prologue data...(mainly so I can just use updateToken(int, String) ). It would also be interesting to see how well XMLModifier benchmarks against xerces. Cheers. -- http://www.ScheduleWorld.com/ Free Google Calendar synchronization with Outlook, Evolution, cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. |
|
From: Jimmy Z. <cra...@co...> - 2006-12-05 04:18:37
|
Mark, My comments below: ----- Original Message ----- From: "Mark Swanson" <ma...@Sc...> To: <vtd...@li...> Sent: Monday, December 04, 2006 7:00 PM Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 > Jimmy Zhang wrote: >> latest benchmarks >> >> http://vtd-xml.sf.net/benchmark.html > > Very impressive, as usual. > > I do have a concern/question: what is the overhead of XPath parsing in > these cases vs coding the queries in Java using the VTDNav class? I > think I remember you posting before that the overhead was negligible, > but I wasn't sure in what context or what circumstances this was the case. > XPath parsing is usually not a big overhead... XPath evaluation performance depends on the complexity of the XPath expression ... simple one (e.g. /*/*/* ) is pretty fast, complex ones, (//*) takes longer, it also has to do with the context of XPath eval. For relative Xpath, if the evaluation only iterates over the entire DOM tree, it will take longer than only evaluting it over a smaller sub tree... this applies to DOM as well as VTD-XML ... > If you have any additional comments in this regard I'd appreciate > reading them. In particular, if you had any performance tips using the > XPath evaluator that would be great. > We will update some of the articles on the website, also there is going to be an article for Javaworld in which XML MOdifier will be disucssed... > Also, I have just found out about XMLModifier. Do you have any example > code that shows how best to use this class? Not that it looks difficult > - I'm just incredibly lazy and just want to copy/paste code that sets up > the VTDNav and calls bind() appropriately. :-) > In the example code there is a directory named "update," in which you will find the example code of using XML Modifier > I couldn't find a way to create a masterDocument with a specific > character set or other prologue data...(mainly so I can just use > updateToken(int, String) ). > masterDocument is really an instance of VTDNav... the way to create one is to parse an XML document... Did I understand this part of your question? > It would also be interesting to see how well XMLModifier benchmarks > against xerces. The bechmark number combines XPath, paring and outputting. Outputting alone will be make the number look even better... > > Cheers. > > -- > http://www.ScheduleWorld.com/ > Free Google Calendar synchronization with Outlook, Evolution, > cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, > Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! > WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > |
|
From: Mark S. <ma...@Sc...> - 2006-12-05 05:42:11
|
>> I do have a concern/question: what is the overhead of XPath parsing in >> these cases vs coding the queries in Java using the VTDNav class? I >> think I remember you posting before that the overhead was negligible, >> but I wasn't sure in what context or what circumstances this was the >> case. >> > > XPath parsing is usually not a big overhead... > XPath evaluation performance depends on the complexity of the XPath > expression ... simple one (e.g. /*/*/* ) is pretty fast, complex ones, > (//*) > takes longer, it also has to do with the context of XPath eval. For > relative > Xpath, if the evaluation only iterates over the entire DOM tree, it will > take longer > than only evaluting it over a smaller sub tree... > this applies to DOM as well as VTD-XML ... Ok, so XPath parsing is fast. I'll just accept that :-) Good to know the eval is smart enough to just walk sub trees. >> If you have any additional comments in this regard I'd appreciate >> reading them. In particular, if you had any performance tips using the >> XPath evaluator that would be great. >> > > We will update some of the articles on the website, also there is going > to be > an article for Javaworld in which XML MOdifier will be disucssed... Looking forward to it. >> Also, I have just found out about XMLModifier. Do you have any example >> code that shows how best to use this class? Not that it looks difficult >> - I'm just incredibly lazy and just want to copy/paste code that sets up >> the VTDNav and calls bind() appropriately. :-) >> > In the example code there is a directory named "update," in which you > will find > the example code of using XML Modifier Ah, thanks. >> I couldn't find a way to create a masterDocument with a specific >> character set or other prologue data...(mainly so I can just use >> updateToken(int, String) ). >> > > masterDocument is really an instance of VTDNav... the way to create one > is to parse an XML document... > > Did I understand this part of your question? I don't think so. Here is an example of what I want to do: I want to use VTD-XML to create an in-memory representation of a document, and then serialize it to a byte[]. What you seem to be saying is that I need to boot-strap this by creating an empty XML document, parse it, and them use XMLModifier to dynamically create the document before serializing it to byte[]. This is important to me for using VTD-XML for tasks other than just routing XML requests. I need to create and modify XML responses as well... Note: The output prologue is very important. I'd like the ability to just create an empty VTDNav, and specify the prologue info (version and encoding attributes are the most important to me). >> It would also be interesting to see how well XMLModifier benchmarks >> against xerces. > > The bechmark number combines XPath, paring and outputting. Outputting > alone will be make the number look even better... Fantastic. Cheers. -- http://www.ScheduleWorld.com/ Free Google Calendar synchronization with Outlook, Evolution, cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. |
|
From: Jimmy Z. <cra...@co...> - 2006-12-05 19:47:01
|
Mark, Creating a document is still something I am comtemplating about.. Any suggestions on what sort of API, method calls that you would like to see ? Jimmy > > I don't think so. Here is an example of what I want to do: > > I want to use VTD-XML to create an in-memory representation of a > document, and then serialize it to a byte[]. > > What you seem to be saying is that I need to boot-strap this by creating > an empty XML document, parse it, and them use XMLModifier to dynamically > create the document before serializing it to byte[]. > > This is important to me for using VTD-XML for tasks other than just > routing XML requests. I need to create and modify XML responses as well... > > Note: The output prologue is very important. > > I'd like the ability to just create an empty VTDNav, and specify the > prologue info (version and encoding attributes are the most important to > me). > >>> It would also be interesting to see how well XMLModifier benchmarks >>> against xerces. >> >> The bechmark number combines XPath, paring and outputting. Outputting >> alone will be make the number look even better... > > Fantastic. > > Cheers. > > > -- > http://www.ScheduleWorld.com/ > Free Google Calendar synchronization with Outlook, Evolution, > cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, > Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! > WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > |
|
From: Mark S. <ma...@Sc...> - 2006-12-05 20:13:26
|
Jimmy Zhang wrote: > Mark, Creating a document is still something I am comtemplating about.. > Any suggestions on what sort of API, method calls that you would like > to see ? >> >> I'd like the ability to just create an empty VTDNav, and specify the >> prologue info (version and encoding attributes are the most important to >> me). For me, that's it. It looks like I can set my own namespace definitions on the root element using the existing API, and using namespaces seems to work by just treating the namespace ":" element name as one big string so that should just work (just guessing as I still haven't played with that). Cheers. -- http://www.ScheduleWorld.com/ Free Google Calendar synchronization with Outlook, Evolution, cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. |
|
From: Jimmy Z. <cra...@co...> - 2006-12-11 02:12:19
|
VTD-XML version 1.9, containing XPath performance fixes and various bug fixes, is now released. This release also contains the benchmark code used for the lastest benchmark report. ----- Original Message ----- From: "Mark Swanson" <ma...@Sc...> To: <vtd...@li...> Sent: Monday, December 04, 2006 9:42 PM Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >>> I do have a concern/question: what is the overhead of XPath parsing in >>> these cases vs coding the queries in Java using the VTDNav class? I >>> think I remember you posting before that the overhead was negligible, >>> but I wasn't sure in what context or what circumstances this was the >>> case. >>> >> >> XPath parsing is usually not a big overhead... >> XPath evaluation performance depends on the complexity of the XPath >> expression ... simple one (e.g. /*/*/* ) is pretty fast, complex ones, >> (//*) >> takes longer, it also has to do with the context of XPath eval. For >> relative >> Xpath, if the evaluation only iterates over the entire DOM tree, it will >> take longer >> than only evaluting it over a smaller sub tree... >> this applies to DOM as well as VTD-XML ... > > Ok, so XPath parsing is fast. I'll just accept that :-) > Good to know the eval is smart enough to just walk sub trees. > >>> If you have any additional comments in this regard I'd appreciate >>> reading them. In particular, if you had any performance tips using the >>> XPath evaluator that would be great. >>> >> >> We will update some of the articles on the website, also there is going >> to be >> an article for Javaworld in which XML MOdifier will be disucssed... > > Looking forward to it. > >>> Also, I have just found out about XMLModifier. Do you have any example >>> code that shows how best to use this class? Not that it looks difficult >>> - I'm just incredibly lazy and just want to copy/paste code that sets up >>> the VTDNav and calls bind() appropriately. :-) >>> >> In the example code there is a directory named "update," in which you >> will find >> the example code of using XML Modifier > > Ah, thanks. > >>> I couldn't find a way to create a masterDocument with a specific >>> character set or other prologue data...(mainly so I can just use >>> updateToken(int, String) ). >>> >> >> masterDocument is really an instance of VTDNav... the way to create one >> is to parse an XML document... >> >> Did I understand this part of your question? > > I don't think so. Here is an example of what I want to do: > > I want to use VTD-XML to create an in-memory representation of a > document, and then serialize it to a byte[]. > > What you seem to be saying is that I need to boot-strap this by creating > an empty XML document, parse it, and them use XMLModifier to dynamically > create the document before serializing it to byte[]. > > This is important to me for using VTD-XML for tasks other than just > routing XML requests. I need to create and modify XML responses as well... > > Note: The output prologue is very important. > > I'd like the ability to just create an empty VTDNav, and specify the > prologue info (version and encoding attributes are the most important to > me). > >>> It would also be interesting to see how well XMLModifier benchmarks >>> against xerces. >> >> The bechmark number combines XPath, paring and outputting. Outputting >> alone will be make the number look even better... > > Fantastic. > > Cheers. > > > -- > http://www.ScheduleWorld.com/ > Free Google Calendar synchronization with Outlook, Evolution, > cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, > Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! > WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > |
|
From: John K. <jk...@in...> - 2006-12-11 07:40:27
|
Elo,
These errors come from the usage of Visual C++-only-functions.
lex.yy.o: In function `yylex':
lex.yy.c:(.text+0xefc): undefined reference to `_wcsdup'
lex.yy.c:(.text+0x1a79): undefined reference to `_wcsdup'
literalExpr.o: In function `evalString_le':
literalExpr.c:(.text+0x18c): undefined reference to `_wcsdup'
numberExpr.o: In function `evalString_ne':
numberExpr.c:(.text+0x151): undefined reference to `_wcsdup'
binaryExpr.o: In function `evalString_be':
binaryExpr.c:(.text+0x131b): undefined reference to `_wcsdup'
binaryExpr.o:binaryExpr.c:(.text+0x1348): more undefined references to
`_wcsdup' follow
collect2: ld returned 1 exit status
Therefor, vtd-xml does not work on GNU systems.
If OK, I'll update the files with the corresponding GNU versions of that
function:
SYNOPSIS
#define _GNU_SOURCE
#include <wchar.h>
wchar_t *wcsdup(const wchar_t *s);
The 1.8 release is broken on this point as well, my fault I hadn't
noticed until now.
Regards,
John Kraal
Jimmy Zhang wrote:
> VTD-XML version 1.9, containing XPath performance fixes and various bug
> fixes, is now released.
> This release also contains the benchmark code used for the lastest benchmark
> report.
> ----- Original Message -----
> From: "Mark Swanson" <ma...@Sc...>
> To: <vtd...@li...>
> Sent: Monday, December 04, 2006 9:42 PM
> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2
>
>
>>>> I do have a concern/question: what is the overhead of XPath parsing in
>>>> these cases vs coding the queries in Java using the VTDNav class? I
>>>> think I remember you posting before that the overhead was negligible,
>>>> but I wasn't sure in what context or what circumstances this was the
>>>> case.
>>>>
>>> XPath parsing is usually not a big overhead...
>>> XPath evaluation performance depends on the complexity of the XPath
>>> expression ... simple one (e.g. /*/*/* ) is pretty fast, complex ones,
>>> (//*)
>>> takes longer, it also has to do with the context of XPath eval. For
>>> relative
>>> Xpath, if the evaluation only iterates over the entire DOM tree, it will
>>> take longer
>>> than only evaluting it over a smaller sub tree...
>>> this applies to DOM as well as VTD-XML ...
>> Ok, so XPath parsing is fast. I'll just accept that :-)
>> Good to know the eval is smart enough to just walk sub trees.
>>
>>>> If you have any additional comments in this regard I'd appreciate
>>>> reading them. In particular, if you had any performance tips using the
>>>> XPath evaluator that would be great.
>>>>
>>> We will update some of the articles on the website, also there is going
>>> to be
>>> an article for Javaworld in which XML MOdifier will be disucssed...
>> Looking forward to it.
>>
>>>> Also, I have just found out about XMLModifier. Do you have any example
>>>> code that shows how best to use this class? Not that it looks difficult
>>>> - I'm just incredibly lazy and just want to copy/paste code that sets up
>>>> the VTDNav and calls bind() appropriately. :-)
>>>>
>>> In the example code there is a directory named "update," in which you
>>> will find
>>> the example code of using XML Modifier
>> Ah, thanks.
>>
>>>> I couldn't find a way to create a masterDocument with a specific
>>>> character set or other prologue data...(mainly so I can just use
>>>> updateToken(int, String) ).
>>>>
>>> masterDocument is really an instance of VTDNav... the way to create one
>>> is to parse an XML document...
>>>
>>> Did I understand this part of your question?
>> I don't think so. Here is an example of what I want to do:
>>
>> I want to use VTD-XML to create an in-memory representation of a
>> document, and then serialize it to a byte[].
>>
>> What you seem to be saying is that I need to boot-strap this by creating
>> an empty XML document, parse it, and them use XMLModifier to dynamically
>> create the document before serializing it to byte[].
>>
>> This is important to me for using VTD-XML for tasks other than just
>> routing XML requests. I need to create and modify XML responses as well...
>>
>> Note: The output prologue is very important.
>>
>> I'd like the ability to just create an empty VTDNav, and specify the
>> prologue info (version and encoding attributes are the most important to
>> me).
>>
>>>> It would also be interesting to see how well XMLModifier benchmarks
>>>> against xerces.
>>> The bechmark number combines XPath, paring and outputting. Outputting
>>> alone will be make the number look even better...
>> Fantastic.
>>
>> Cheers.
>>
>>
>> --
>> http://www.ScheduleWorld.com/
>> Free Google Calendar synchronization with Outlook, Evolution,
>> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird,
>> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts!
>> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support.
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share
>> your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Vtd-xml-users mailing list
>> Vtd...@li...
>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
>>
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Vtd-xml-users mailing list
> Vtd...@li...
> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
|
|
From: Jimmy Z. <cra...@co...> - 2007-01-05 02:54:33
|
The benchmark report on XPath evaluation performance comparison http://www.ximpleware.com/benchmark_xpath.html |
|
From: Jimmy Z. <cra...@co...> - 2007-01-10 19:01:14
|
More data points concerning the performance of DOM and VTD-XML http://www.javaworld.com/javaworld/jw-01-2007/jw-01-vtd.html |
|
From: Jimmy Z. <cra...@co...> - 2007-01-08 03:00:48
|
A quick update on XPath performance, added test results for Jaxen 1.1 http://www.ximpleware.com/benchmark_xpath.html ----- Original Message ----- From: "Jimmy Zhang" <cra...@co...> Cc: <vtd...@li...> Sent: Thursday, January 04, 2007 6:53 PM Subject: [Vtd-xml-users] latest benchmark result > The benchmark report on XPath evaluation performance comparison > > http://www.ximpleware.com/benchmark_xpath.html > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > |
|
From: Jimmy Z. <cra...@co...> - 2006-12-11 02:20:41
|
http://sourceforge.net/project/showfiles.php?group_id=110612 :) ----- Original Message ----- From: "Jimmy Zhang" <cra...@co...> To: "Mark Swanson" <ma...@Sc...>; <vtd...@li...> Sent: Sunday, December 10, 2006 6:11 PM Subject: [Vtd-xml-users] vtd-xml 1.9 released > VTD-XML version 1.9, containing XPath performance fixes and various bug > fixes, is now released. > This release also contains the benchmark code used for the lastest > benchmark > report. > ----- Original Message ----- > From: "Mark Swanson" <ma...@Sc...> > To: <vtd...@li...> > Sent: Monday, December 04, 2006 9:42 PM > Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 > > >>>> I do have a concern/question: what is the overhead of XPath parsing in >>>> these cases vs coding the queries in Java using the VTDNav class? I >>>> think I remember you posting before that the overhead was negligible, >>>> but I wasn't sure in what context or what circumstances this was the >>>> case. >>>> >>> >>> XPath parsing is usually not a big overhead... >>> XPath evaluation performance depends on the complexity of the XPath >>> expression ... simple one (e.g. /*/*/* ) is pretty fast, complex ones, >>> (//*) >>> takes longer, it also has to do with the context of XPath eval. For >>> relative >>> Xpath, if the evaluation only iterates over the entire DOM tree, it will >>> take longer >>> than only evaluting it over a smaller sub tree... >>> this applies to DOM as well as VTD-XML ... >> >> Ok, so XPath parsing is fast. I'll just accept that :-) >> Good to know the eval is smart enough to just walk sub trees. >> >>>> If you have any additional comments in this regard I'd appreciate >>>> reading them. In particular, if you had any performance tips using the >>>> XPath evaluator that would be great. >>>> >>> >>> We will update some of the articles on the website, also there is going >>> to be >>> an article for Javaworld in which XML MOdifier will be disucssed... >> >> Looking forward to it. >> >>>> Also, I have just found out about XMLModifier. Do you have any example >>>> code that shows how best to use this class? Not that it looks difficult >>>> - I'm just incredibly lazy and just want to copy/paste code that sets >>>> up >>>> the VTDNav and calls bind() appropriately. :-) >>>> >>> In the example code there is a directory named "update," in which you >>> will find >>> the example code of using XML Modifier >> >> Ah, thanks. >> >>>> I couldn't find a way to create a masterDocument with a specific >>>> character set or other prologue data...(mainly so I can just use >>>> updateToken(int, String) ). >>>> >>> >>> masterDocument is really an instance of VTDNav... the way to create one >>> is to parse an XML document... >>> >>> Did I understand this part of your question? >> >> I don't think so. Here is an example of what I want to do: >> >> I want to use VTD-XML to create an in-memory representation of a >> document, and then serialize it to a byte[]. >> >> What you seem to be saying is that I need to boot-strap this by creating >> an empty XML document, parse it, and them use XMLModifier to dynamically >> create the document before serializing it to byte[]. >> >> This is important to me for using VTD-XML for tasks other than just >> routing XML requests. I need to create and modify XML responses as >> well... >> >> Note: The output prologue is very important. >> >> I'd like the ability to just create an empty VTDNav, and specify the >> prologue info (version and encoding attributes are the most important to >> me). >> >>>> It would also be interesting to see how well XMLModifier benchmarks >>>> against xerces. >>> >>> The bechmark number combines XPath, paring and outputting. Outputting >>> alone will be make the number look even better... >> >> Fantastic. >> >> Cheers. >> >> >> -- >> http://www.ScheduleWorld.com/ >> Free Google Calendar synchronization with Outlook, Evolution, >> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, >> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! >> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Vtd-xml-users mailing list >> Vtd...@li... >> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >> > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > |
|
From: Jimmy Z. <cra...@co...> - 2006-12-11 08:42:40
|
John, Thanks for pointing that out, as to the fix what about defining a macro #define _wcsdup wcsdup on my cygwin gcc compiler, _wcsdup is actually defined... Jimmy ----- Original Message ----- From: "John Kraal" <jk...@in...> To: "Jimmy Zhang" <cra...@co...> Cc: "Mark Swanson" <ma...@Sc...>; <vtd...@li...> Sent: Sunday, December 10, 2006 11:40 PM Subject: Re: [Vtd-xml-users] vtd-xml 1.9 released > Elo, > > These errors come from the usage of Visual C++-only-functions. > > lex.yy.o: In function `yylex': > lex.yy.c:(.text+0xefc): undefined reference to `_wcsdup' > lex.yy.c:(.text+0x1a79): undefined reference to `_wcsdup' > literalExpr.o: In function `evalString_le': > literalExpr.c:(.text+0x18c): undefined reference to `_wcsdup' > numberExpr.o: In function `evalString_ne': > numberExpr.c:(.text+0x151): undefined reference to `_wcsdup' > binaryExpr.o: In function `evalString_be': > binaryExpr.c:(.text+0x131b): undefined reference to `_wcsdup' > binaryExpr.o:binaryExpr.c:(.text+0x1348): more undefined references to > `_wcsdup' follow > collect2: ld returned 1 exit status > > Therefor, vtd-xml does not work on GNU systems. > > If OK, I'll update the files with the corresponding GNU versions of that > function: > > SYNOPSIS > #define _GNU_SOURCE > #include <wchar.h> > > wchar_t *wcsdup(const wchar_t *s); > > The 1.8 release is broken on this point as well, my fault I hadn't > noticed until now. > > Regards, > > John Kraal > > Jimmy Zhang wrote: >> VTD-XML version 1.9, containing XPath performance fixes and various bug >> fixes, is now released. >> This release also contains the benchmark code used for the lastest >> benchmark >> report. >> ----- Original Message ----- >> From: "Mark Swanson" <ma...@Sc...> >> To: <vtd...@li...> >> Sent: Monday, December 04, 2006 9:42 PM >> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >> >> >>>>> I do have a concern/question: what is the overhead of XPath parsing in >>>>> these cases vs coding the queries in Java using the VTDNav class? I >>>>> think I remember you posting before that the overhead was negligible, >>>>> but I wasn't sure in what context or what circumstances this was the >>>>> case. >>>>> >>>> XPath parsing is usually not a big overhead... >>>> XPath evaluation performance depends on the complexity of the XPath >>>> expression ... simple one (e.g. /*/*/* ) is pretty fast, complex ones, >>>> (//*) >>>> takes longer, it also has to do with the context of XPath eval. For >>>> relative >>>> Xpath, if the evaluation only iterates over the entire DOM tree, it >>>> will >>>> take longer >>>> than only evaluting it over a smaller sub tree... >>>> this applies to DOM as well as VTD-XML ... >>> Ok, so XPath parsing is fast. I'll just accept that :-) >>> Good to know the eval is smart enough to just walk sub trees. >>> >>>>> If you have any additional comments in this regard I'd appreciate >>>>> reading them. In particular, if you had any performance tips using the >>>>> XPath evaluator that would be great. >>>>> >>>> We will update some of the articles on the website, also there is going >>>> to be >>>> an article for Javaworld in which XML MOdifier will be disucssed... >>> Looking forward to it. >>> >>>>> Also, I have just found out about XMLModifier. Do you have any example >>>>> code that shows how best to use this class? Not that it looks >>>>> difficult >>>>> - I'm just incredibly lazy and just want to copy/paste code that sets >>>>> up >>>>> the VTDNav and calls bind() appropriately. :-) >>>>> >>>> In the example code there is a directory named "update," in which you >>>> will find >>>> the example code of using XML Modifier >>> Ah, thanks. >>> >>>>> I couldn't find a way to create a masterDocument with a specific >>>>> character set or other prologue data...(mainly so I can just use >>>>> updateToken(int, String) ). >>>>> >>>> masterDocument is really an instance of VTDNav... the way to create one >>>> is to parse an XML document... >>>> >>>> Did I understand this part of your question? >>> I don't think so. Here is an example of what I want to do: >>> >>> I want to use VTD-XML to create an in-memory representation of a >>> document, and then serialize it to a byte[]. >>> >>> What you seem to be saying is that I need to boot-strap this by creating >>> an empty XML document, parse it, and them use XMLModifier to dynamically >>> create the document before serializing it to byte[]. >>> >>> This is important to me for using VTD-XML for tasks other than just >>> routing XML requests. I need to create and modify XML responses as >>> well... >>> >>> Note: The output prologue is very important. >>> >>> I'd like the ability to just create an empty VTDNav, and specify the >>> prologue info (version and encoding attributes are the most important to >>> me). >>> >>>>> It would also be interesting to see how well XMLModifier benchmarks >>>>> against xerces. >>>> The bechmark number combines XPath, paring and outputting. Outputting >>>> alone will be make the number look even better... >>> Fantastic. >>> >>> Cheers. >>> >>> >>> -- >>> http://www.ScheduleWorld.com/ >>> Free Google Calendar synchronization with Outlook, Evolution, >>> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, >>> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! >>> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. >>> >>> ------------------------------------------------------------------------- >>> Take Surveys. Earn Cash. Influence the Future of IT >>> Join SourceForge.net's Techsay panel and you'll get the chance to share >>> your >>> opinions on IT & business topics through brief surveys - and earn cash >>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>> _______________________________________________ >>> Vtd-xml-users mailing list >>> Vtd...@li... >>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >>> >> >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Vtd-xml-users mailing list >> Vtd...@li... >> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > |
|
From: Jimmy Z. <cra...@co...> - 2006-12-11 08:58:26
|
go to file download and XML files are in the benchmark_1.9.zip ----- Original Message ----- From: "John Kraal" <jk...@in...> To: "Jimmy Zhang" <cra...@co...> Sent: Monday, December 11, 2006 12:48 AM Subject: Re: [Vtd-xml-users] vtd-xml 1.9 released > Right, will do that next time (and for release), I simply did a > s/_wcsdup/wcsdup/g :). > > In any case, do you have the XML files for benchmarking available yet? > I've got a libxml2, vtdxml1.7, 1.8, 1.9, .Net's System.Xml.XPath (on > Mono) standing by :-) > > Jimmy Zhang wrote: >> John, Thanks for pointing that out, as to the fix what about defining a >> macro >> >> #define _wcsdup wcsdup >> >> on my cygwin gcc compiler, _wcsdup is actually defined... >> >> Jimmy >> ----- Original Message ----- From: "John Kraal" <jk...@in...> >> To: "Jimmy Zhang" <cra...@co...> >> Cc: "Mark Swanson" <ma...@Sc...>; >> <vtd...@li...> >> Sent: Sunday, December 10, 2006 11:40 PM >> Subject: Re: [Vtd-xml-users] vtd-xml 1.9 released >> >> >>> Elo, >>> >>> These errors come from the usage of Visual C++-only-functions. >>> >>> lex.yy.o: In function `yylex': >>> lex.yy.c:(.text+0xefc): undefined reference to `_wcsdup' >>> lex.yy.c:(.text+0x1a79): undefined reference to `_wcsdup' >>> literalExpr.o: In function `evalString_le': >>> literalExpr.c:(.text+0x18c): undefined reference to `_wcsdup' >>> numberExpr.o: In function `evalString_ne': >>> numberExpr.c:(.text+0x151): undefined reference to `_wcsdup' >>> binaryExpr.o: In function `evalString_be': >>> binaryExpr.c:(.text+0x131b): undefined reference to `_wcsdup' >>> binaryExpr.o:binaryExpr.c:(.text+0x1348): more undefined references to >>> `_wcsdup' follow >>> collect2: ld returned 1 exit status >>> >>> Therefor, vtd-xml does not work on GNU systems. >>> >>> If OK, I'll update the files with the corresponding GNU versions of that >>> function: >>> >>> SYNOPSIS >>> #define _GNU_SOURCE >>> #include <wchar.h> >>> >>> wchar_t *wcsdup(const wchar_t *s); >>> >>> The 1.8 release is broken on this point as well, my fault I hadn't >>> noticed until now. >>> >>> Regards, >>> >>> John Kraal >>> >>> Jimmy Zhang wrote: >>>> VTD-XML version 1.9, containing XPath performance fixes and various bug >>>> fixes, is now released. >>>> This release also contains the benchmark code used for the lastest >>>> benchmark >>>> report. >>>> ----- Original Message ----- From: "Mark Swanson" >>>> <ma...@Sc...> >>>> To: <vtd...@li...> >>>> Sent: Monday, December 04, 2006 9:42 PM >>>> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >>>> >>>> >>>>>>> I do have a concern/question: what is the overhead of XPath >>>>>>> parsing in >>>>>>> these cases vs coding the queries in Java using the VTDNav class? I >>>>>>> think I remember you posting before that the overhead was >>>>>>> negligible, >>>>>>> but I wasn't sure in what context or what circumstances this was the >>>>>>> case. >>>>>>> >>>>>> XPath parsing is usually not a big overhead... >>>>>> XPath evaluation performance depends on the complexity of the XPath >>>>>> expression ... simple one (e.g. /*/*/* ) is pretty fast, complex >>>>>> ones, >>>>>> (//*) >>>>>> takes longer, it also has to do with the context of XPath eval. For >>>>>> relative >>>>>> Xpath, if the evaluation only iterates over the entire DOM tree, it >>>>>> will >>>>>> take longer >>>>>> than only evaluting it over a smaller sub tree... >>>>>> this applies to DOM as well as VTD-XML ... >>>>> Ok, so XPath parsing is fast. I'll just accept that :-) >>>>> Good to know the eval is smart enough to just walk sub trees. >>>>> >>>>>>> If you have any additional comments in this regard I'd appreciate >>>>>>> reading them. In particular, if you had any performance tips using >>>>>>> the >>>>>>> XPath evaluator that would be great. >>>>>>> >>>>>> We will update some of the articles on the website, also there is >>>>>> going >>>>>> to be >>>>>> an article for Javaworld in which XML MOdifier will be disucssed... >>>>> Looking forward to it. >>>>> >>>>>>> Also, I have just found out about XMLModifier. Do you have any >>>>>>> example >>>>>>> code that shows how best to use this class? Not that it looks >>>>>>> difficult >>>>>>> - I'm just incredibly lazy and just want to copy/paste code that >>>>>>> sets up >>>>>>> the VTDNav and calls bind() appropriately. :-) >>>>>>> >>>>>> In the example code there is a directory named "update," in which you >>>>>> will find >>>>>> the example code of using XML Modifier >>>>> Ah, thanks. >>>>> >>>>>>> I couldn't find a way to create a masterDocument with a specific >>>>>>> character set or other prologue data...(mainly so I can just use >>>>>>> updateToken(int, String) ). >>>>>>> >>>>>> masterDocument is really an instance of VTDNav... the way to create >>>>>> one >>>>>> is to parse an XML document... >>>>>> >>>>>> Did I understand this part of your question? >>>>> I don't think so. Here is an example of what I want to do: >>>>> >>>>> I want to use VTD-XML to create an in-memory representation of a >>>>> document, and then serialize it to a byte[]. >>>>> >>>>> What you seem to be saying is that I need to boot-strap this by >>>>> creating >>>>> an empty XML document, parse it, and them use XMLModifier to >>>>> dynamically >>>>> create the document before serializing it to byte[]. >>>>> >>>>> This is important to me for using VTD-XML for tasks other than just >>>>> routing XML requests. I need to create and modify XML responses as >>>>> well... >>>>> >>>>> Note: The output prologue is very important. >>>>> >>>>> I'd like the ability to just create an empty VTDNav, and specify the >>>>> prologue info (version and encoding attributes are the most >>>>> important to >>>>> me). >>>>> >>>>>>> It would also be interesting to see how well XMLModifier benchmarks >>>>>>> against xerces. >>>>>> The bechmark number combines XPath, paring and outputting. Outputting >>>>>> alone will be make the number look even better... >>>>> Fantastic. >>>>> >>>>> Cheers. >>>>> >>>>> >>>>> -- >>>>> http://www.ScheduleWorld.com/ >>>>> Free Google Calendar synchronization with Outlook, Evolution, >>>>> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, >>>>> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! >>>>> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. >>>>> >>>>> ------------------------------------------------------------------------- >>>>> >>>>> Take Surveys. Earn Cash. Influence the Future of IT >>>>> Join SourceForge.net's Techsay panel and you'll get the chance to >>>>> share >>>>> your >>>>> opinions on IT & business topics through brief surveys - and earn cash >>>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>>> >>>>> _______________________________________________ >>>>> Vtd-xml-users mailing list >>>>> Vtd...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> Take Surveys. Earn Cash. Influence the Future of IT >>>> Join SourceForge.net's Techsay panel and you'll get the chance to >>>> share your >>>> opinions on IT & business topics through brief surveys - and earn cash >>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>> >>>> _______________________________________________ >>>> Vtd-xml-users mailing list >>>> Vtd...@li... >>>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >>> >> >> > |
|
From: Jimmy Z. <cra...@co...> - 2006-12-13 08:18:46
|
If you want to benchmark VTD-XML for very large files, you might have to tune a few things such as the width of intHash, the way to do it is to change the implementation of a function called determineHashWidth()... Let me know if you need help on this... ----- Original Message ----- From: "John Kraal" <jk...@in...> To: "Jimmy Zhang" <cra...@co...> Sent: Monday, December 11, 2006 12:48 AM Subject: Re: [Vtd-xml-users] vtd-xml 1.9 released > Right, will do that next time (and for release), I simply did a > s/_wcsdup/wcsdup/g :). > > In any case, do you have the XML files for benchmarking available yet? > I've got a libxml2, vtdxml1.7, 1.8, 1.9, .Net's System.Xml.XPath (on > Mono) standing by :-) > > Jimmy Zhang wrote: >> John, Thanks for pointing that out, as to the fix what about defining a >> macro >> >> #define _wcsdup wcsdup >> >> on my cygwin gcc compiler, _wcsdup is actually defined... >> >> Jimmy >> ----- Original Message ----- From: "John Kraal" <jk...@in...> >> To: "Jimmy Zhang" <cra...@co...> >> Cc: "Mark Swanson" <ma...@Sc...>; >> <vtd...@li...> >> Sent: Sunday, December 10, 2006 11:40 PM >> Subject: Re: [Vtd-xml-users] vtd-xml 1.9 released >> >> >>> Elo, >>> >>> These errors come from the usage of Visual C++-only-functions. >>> >>> lex.yy.o: In function `yylex': >>> lex.yy.c:(.text+0xefc): undefined reference to `_wcsdup' >>> lex.yy.c:(.text+0x1a79): undefined reference to `_wcsdup' >>> literalExpr.o: In function `evalString_le': >>> literalExpr.c:(.text+0x18c): undefined reference to `_wcsdup' >>> numberExpr.o: In function `evalString_ne': >>> numberExpr.c:(.text+0x151): undefined reference to `_wcsdup' >>> binaryExpr.o: In function `evalString_be': >>> binaryExpr.c:(.text+0x131b): undefined reference to `_wcsdup' >>> binaryExpr.o:binaryExpr.c:(.text+0x1348): more undefined references to >>> `_wcsdup' follow >>> collect2: ld returned 1 exit status >>> >>> Therefor, vtd-xml does not work on GNU systems. >>> >>> If OK, I'll update the files with the corresponding GNU versions of that >>> function: >>> >>> SYNOPSIS >>> #define _GNU_SOURCE >>> #include <wchar.h> >>> >>> wchar_t *wcsdup(const wchar_t *s); >>> >>> The 1.8 release is broken on this point as well, my fault I hadn't >>> noticed until now. >>> >>> Regards, >>> >>> John Kraal >>> >>> Jimmy Zhang wrote: >>>> VTD-XML version 1.9, containing XPath performance fixes and various bug >>>> fixes, is now released. >>>> This release also contains the benchmark code used for the lastest >>>> benchmark >>>> report. >>>> ----- Original Message ----- From: "Mark Swanson" >>>> <ma...@Sc...> >>>> To: <vtd...@li...> >>>> Sent: Monday, December 04, 2006 9:42 PM >>>> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >>>> >>>> >>>>>>> I do have a concern/question: what is the overhead of XPath >>>>>>> parsing in >>>>>>> these cases vs coding the queries in Java using the VTDNav class? I >>>>>>> think I remember you posting before that the overhead was >>>>>>> negligible, >>>>>>> but I wasn't sure in what context or what circumstances this was the >>>>>>> case. >>>>>>> >>>>>> XPath parsing is usually not a big overhead... >>>>>> XPath evaluation performance depends on the complexity of the XPath >>>>>> expression ... simple one (e.g. /*/*/* ) is pretty fast, complex >>>>>> ones, >>>>>> (//*) >>>>>> takes longer, it also has to do with the context of XPath eval. For >>>>>> relative >>>>>> Xpath, if the evaluation only iterates over the entire DOM tree, it >>>>>> will >>>>>> take longer >>>>>> than only evaluting it over a smaller sub tree... >>>>>> this applies to DOM as well as VTD-XML ... >>>>> Ok, so XPath parsing is fast. I'll just accept that :-) >>>>> Good to know the eval is smart enough to just walk sub trees. >>>>> >>>>>>> If you have any additional comments in this regard I'd appreciate >>>>>>> reading them. In particular, if you had any performance tips using >>>>>>> the >>>>>>> XPath evaluator that would be great. >>>>>>> >>>>>> We will update some of the articles on the website, also there is >>>>>> going >>>>>> to be >>>>>> an article for Javaworld in which XML MOdifier will be disucssed... >>>>> Looking forward to it. >>>>> >>>>>>> Also, I have just found out about XMLModifier. Do you have any >>>>>>> example >>>>>>> code that shows how best to use this class? Not that it looks >>>>>>> difficult >>>>>>> - I'm just incredibly lazy and just want to copy/paste code that >>>>>>> sets up >>>>>>> the VTDNav and calls bind() appropriately. :-) >>>>>>> >>>>>> In the example code there is a directory named "update," in which you >>>>>> will find >>>>>> the example code of using XML Modifier >>>>> Ah, thanks. >>>>> >>>>>>> I couldn't find a way to create a masterDocument with a specific >>>>>>> character set or other prologue data...(mainly so I can just use >>>>>>> updateToken(int, String) ). >>>>>>> >>>>>> masterDocument is really an instance of VTDNav... the way to create >>>>>> one >>>>>> is to parse an XML document... >>>>>> >>>>>> Did I understand this part of your question? >>>>> I don't think so. Here is an example of what I want to do: >>>>> >>>>> I want to use VTD-XML to create an in-memory representation of a >>>>> document, and then serialize it to a byte[]. >>>>> >>>>> What you seem to be saying is that I need to boot-strap this by >>>>> creating >>>>> an empty XML document, parse it, and them use XMLModifier to >>>>> dynamically >>>>> create the document before serializing it to byte[]. >>>>> >>>>> This is important to me for using VTD-XML for tasks other than just >>>>> routing XML requests. I need to create and modify XML responses as >>>>> well... >>>>> >>>>> Note: The output prologue is very important. >>>>> >>>>> I'd like the ability to just create an empty VTDNav, and specify the >>>>> prologue info (version and encoding attributes are the most >>>>> important to >>>>> me). >>>>> >>>>>>> It would also be interesting to see how well XMLModifier benchmarks >>>>>>> against xerces. >>>>>> The bechmark number combines XPath, paring and outputting. Outputting >>>>>> alone will be make the number look even better... >>>>> Fantastic. >>>>> >>>>> Cheers. >>>>> >>>>> >>>>> -- >>>>> http://www.ScheduleWorld.com/ >>>>> Free Google Calendar synchronization with Outlook, Evolution, >>>>> cell phones, BlackBerry, PalmOS, Exchange, Mozilla, Thunderbird, >>>>> Pocket PC/Windows Mobile. Also sync tasks, notes and contacts! >>>>> WebDAV, vfreebusy, RSS, LDAP, iCalendar, iTIP, iMIP support. >>>>> >>>>> ------------------------------------------------------------------------- >>>>> >>>>> Take Surveys. Earn Cash. Influence the Future of IT >>>>> Join SourceForge.net's Techsay panel and you'll get the chance to >>>>> share >>>>> your >>>>> opinions on IT & business topics through brief surveys - and earn cash >>>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>>> >>>>> _______________________________________________ >>>>> Vtd-xml-users mailing list >>>>> Vtd...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> Take Surveys. Earn Cash. Influence the Future of IT >>>> Join SourceForge.net's Techsay panel and you'll get the chance to >>>> share your >>>> opinions on IT & business topics through brief surveys - and earn cash >>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>> >>>> _______________________________________________ >>>> Vtd-xml-users mailing list >>>> Vtd...@li... >>>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >>> >> >> > |
|
From: Jimmy Z. <cra...@co...> - 2006-12-05 08:14:55
|
will release the code and xml files into a zip file soon... ----- Original Message ----- From: "John Kraal" <jk...@in...> To: "Jimmy Zhang" <cra...@co...> Sent: Tuesday, December 05, 2006 12:02 AM Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 > I'll rebuild my programs and use your xml files for reference. > > Jimmy Zhang wrote: >> latest benchmarks >> >> http://vtd-xml.sf.net/benchmark.html >> >> >> ----- Original Message ----- >> *From:* John Kraal <mailto:jk...@in...> >> *To:* Jimmy Zhang <mailto:cra...@co...> >> *Sent:* Thursday, November 30, 2006 12:34 AM >> *Subject:* RE: [Vtd-xml-users] Performance in comparison to libxml2 >> >> Jimmy, >> >> I ran the tests multiple times to include startup and shutdown >> processing. I could create a loop doing 50 to 100 tests if that's >> what you prefer (or like to see). >> >> Creating strings is the actual retrieving of node data; looks quite >> important to me.. >> >> -----Original Message----- >> From: Jimmy Zhang [mailto:cra...@co...] >> Sent: Thu 30-11-2006 4:22 >> To: John Kraal >> Cc: vtd...@li... >> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >> >> Benchmarks usualy iterate the test for a large numbers before taking >> the >> average >> for each iteration, this is especially important for Java because >> server JVM >> takes >> some iterations to warm up ... >> Also Is there a need for creating strings?? A smart work around may >> exist to >> completely >> bypass this stage... >> ----- Original Message ----- >> From: "John Kraal" <jk...@in...> >> To: "Jimmy Zhang" <cra...@co...> >> Sent: Tuesday, November 28, 2006 11:48 PM >> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >> >> >> > In order >> > >> > * I used 1.8; but indeed I should've tested the java-cvs as well. >> > * Test code included; jkl.files.xml is described somewhat earlier >> (137 >> > mb) and the other attached as well. >> > * Java 1.5 something, it's a pain to get that installed and >> uninstalled >> > on Debian (Debian mindset: Proprietary software is evil) >> > * Parsing is actually reading the file and making it workable; >> maybe >> > that just didn't change significantly? >> > * I really cannot explain.. I believe it is now about the same >> speed as >> > '//*' >> > >> > Jimmy Zhang wrote: >> >> looks interesting.. a few things >> >> >> >> * you should check out the latest java version for the testing as >> well >> >> since there has been changes >> >> * What are the test code and conditions? We are doing a bit of >> >> benchmarking >> >> ourselves, mostly with modest file sizes... >> >> >> >> * for java version ,did you use server JVM, that makes a hell of >> >> difference?? >> >> >> >> I read it a bit more, there are more questions than answers... >> >> * from vtd-xml-c to vtdxml 1.8 cvs, there is no change at all >> >> at the parsing code, why there is a big difference in >> performance? >> >> >> >> * how come //*[local-name()="Descriptor"] takes shorter amoutn >> >> of time than //* >> >> ----- Original Message ----- From: "John Kraal" >> <jk...@in...> >> >> To: "Jimmy Zhang" <cra...@co...> >> >> Sent: Tuesday, November 28, 2006 4:38 AM >> >> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >> >> >> >> >> >>> I've tested the CVS version and included the results I've >> recorded until >> >>> now. I'm actually a bit too lazy to build other java-parsers to >> test >> >>> with, but it indicates a little of the C performance. >> >>> >> >>> I'm interested in your opinion on this before continuing with >> testing.. >> >>> >> >>> Regards, >> >>> John >> >>> >> >>> Jimmy Zhang wrote: >> >>>> There has been some significant XPath eval performance >> enhancement >> >>>> slated >> >>>> for next release, if you want to give a try, it is also in CVS >> moments >> >>>> ago... >> >>>> ----- Original Message ----- From: "John Kraal" >> <jk...@in...> >> >>>> To: "Jimmy Zhang" <cra...@co...> >> >>>> Sent: Tuesday, November 21, 2006 12:38 AM >> >>>> Subject: Re: [Vtd-xml-users] Performance in comparison to >> libxml2 >> >>>> >> >>>> >> >>>>> What failed exactly? Anyway, I'll do what I can; just notify >> me when >> >>>>> you >> >>>>> release 1.8. >> >>>>> >> >>>>> regards, >> >>>>> John >> >>>>> >> >>>>> Jimmy Zhang wrote: >> >>>>>> John, I wasn't able to get the toolchain script to work? >> >>>>>> Can you help us create another tar.gz release after the >> release of >> >>>>>> 1.8 >> >>>>>> in a few days.. >> >>>>>> Jimmy >> >>>>>> ----- Original Message ----- From: "John Kraal" >> <jk...@in...> >> >>>>>> To: "Jimmy Zhang" <cra...@co...> >> >>>>>> Cc: <vtd...@li...> >> >>>>>> Sent: Tuesday, November 07, 2006 12:12 AM >> >>>>>> Subject: Re: [Vtd-xml-users] Performance in comparison to >> libxml2 >> >>>>>> >> >>>>>> >> >>>>>>> No, I'm sorry - the files I used to test contains data from >> my >> >>>>>>> employer; >> >>>>>>> I will not be the one to distribute that :-). But it's quite >> easy to >> >>>>>>> create a fairly simple xml file like mine; and test it. >> >>>>>>> >> >>>>>>> Remember that I'm not testing a Java application, but merely >> C. >> >>>>>>> >> >>>>>>> The sources are in the previous email. >> >>>>>>> >> >>>>>>> The structure is quite simple, and as I'm not able to create >> a XSD >> >>>>>>> schema from a XML File easily (not really sure with what), >> here the >> >>>>>>> structure at it's simplest, just add some elements: >> >>>>>>> >> >>>>>>> <shipments> >> >>>>>>> <shipment dosvlg="123" afd="abc123"> >> >>>>>>> <from>NLAMS</from> >> >>>>>>> <to>NLRTM</to> >> >>>>>>> <goods> >> >>>>>>> <goodsline> >> >>>>>>> <merknr>abc</merknr> >> >>>>>>> <col code="pl">12345</col> >> >>>>>>> </goodsline> >> >>>>>>> </goods> >> >>>>>>> <relations> >> >>>>>>> <relation srtnaw="123" tsroln="123" relnr="123" zoek="abc"> >> >>>>>>> <tsnam1>abc</tsnam1> >> >>>>>>> <coordinates> >> >>>>>>> <tscoox>-12.3456</tscoox> >> >>>>>>> <tscooy>-12.3456</tscoox> >> >>>>>>> </coordinates> >> >>>>>>> </relation> >> >>>>>>> </relations> >> >>>>>>> </shipment> >> >>>>>>> </shipments> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> Jimmy Zhang wrote: >> >>>>>>>> Can you provide a few sample XML files that you used for the >> >>>>>>>> testing? >> >>>>>>>> >> >>>>>>>> I am sure there can be additioal performance tuning for >> performance >> >>>>>>>> evaluation... >> >>>>>>>> >> >>>>>>>> So far the response we got compare VTD-XML favorably with >> Xerces... >> >>>>>>>> for the java version.. >> >>>>>>>> ----- Original Message ----- From: "John Kraal - Kewill >> >>>>>>>> Interchain NL" >> >>>>>>>> <jk...@in...> >> >>>>>>>> To: <vtd...@li...> >> >>>>>>>> Sent: Monday, November 06, 2006 4:23 AM >> >>>>>>>> Subject: [Vtd-xml-users] Performance in comparison to >> libxml2 >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> Hello, >> >>>>>>>>> >> >>>>>>>>> I've been playing with vtdxml for a while now, and my >> latest >> >>>>>>>>> experience >> >>>>>>>>> is not very encouraging to go on :(... >> >>>>>>>>> >> >>>>>>>>> I have created a file with _lots_ of recurring structures >> and >> >>>>>>>>> amounts of >> >>>>>>>>> recurring data (about 137 MB), eventually I created a xpath >> to >> >>>>>>>>> select >> >>>>>>>>> the name of every relation in the 4th role (doesn't really >> >>>>>>>>> matter). >> >>>>>>>>> >> >>>>>>>>> So, I executed it, with the code included for vtdxml (see >> >>>>>>>>> vtdxml.c), >> >>>>>>>>> and >> >>>>>>>>> it performed like this: >> >>>>>>>>> >> >>>>>>>>> unims@gxvm1:~/src/xmltest$ time ./test ./jkl.files.xml >> >>>>>>>>> '//relation[@tsroln=04]/tsnam1' >> /dev/null >> >>>>>>>>> >> >>>>>>>>> real 0m4.940s >> >>>>>>>>> user 0m4.625s >> >>>>>>>>> sys 0m0.256s >> >>>>>>>>> >> >>>>>>>>> With 162450 bytes of terminal output. >> >>>>>>>>> >> >>>>>>>>> Then, the horrible thing happened, I used lixml2 with an >> adjusted >> >>>>>>>>> reference xpath-program. (xpath1.c from their website, >> only with >> >>>>>>>>> content >> >>>>>>>>> retrieval): >> >>>>>>>>> >> >>>>>>>>> unims@gxvm1:~/src/libxmltest$ time ./test ./jkl.files.xml >> >>>>>>>>> '//relation[@tsroln=04]/tsnam1' >> /dev/null >> >>>>>>>>> >> >>>>>>>>> real 0m2.545s >> >>>>>>>>> user 0m2.201s >> >>>>>>>>> sys 0m0.321s >> >>>>>>>>> >> >>>>>>>>> The size of the output was 150808 bytes. >> >>>>>>>>> >> >>>>>>>>> This is an incredible difference, am I doing something >> wrong? Or >> >>>>>>>>> did I >> >>>>>>>>> have too many expectations of vtd? >> >>>>>>>>> >> >>>>>>>>> Regards, >> >>>>>>>>> John Kraal >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> -------------------------------------------------------------------------------- >> >>>>>>>>\ >> >>>>>>>>> >> ------------------------------------------------------------------------- >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Using Tomcat but need to do more? Need to support web >> services, >> >>>>>>>>> security? >> >>>>>>>>> Get stuff done quickly with pre-integrated technology to >> make your >> >>>>>>>>> job >> >>>>>>>>> easier >> >>>>>>>>> Download IBM WebSphere Application Server v.1.0.1 based on >> Apache >> >>>>>>>>> Geronimo >> >>>>>>>>> >> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >> >> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> -------------------------------------------------------------------------------- >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> Vtd-xml-users mailing list >> >>>>>>>>> Vtd...@li... >> >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>> = >> > |
|
From: Jimmy Z. <cra...@co...> - 2006-12-05 08:20:15
|
Caveat emptor: C# version of VTD-XML is the slowest among it C, Java versions... ----- Original Message ----- From: "John Kraal" <jk...@in...> To: "Jimmy Zhang" <cra...@co...> Sent: Tuesday, December 05, 2006 12:17 AM Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 > hooray \o/ > > I also managed to create a C# test using the native System.Xml thingies; > yet .net seems to lack a high performance timer (without the use of > kernel.dll functions). But I'll include those results as well whenever I > can :-) > > Jimmy Zhang wrote: >> will release the code and xml files into a zip file soon... >> ----- Original Message ----- From: "John Kraal" <jk...@in...> >> To: "Jimmy Zhang" <cra...@co...> >> Sent: Tuesday, December 05, 2006 12:02 AM >> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >> >> >>> I'll rebuild my programs and use your xml files for reference. >>> >>> Jimmy Zhang wrote: >>>> latest benchmarks >>>> >>>> http://vtd-xml.sf.net/benchmark.html >>>> >>>> >>>> ----- Original Message ----- >>>> *From:* John Kraal <mailto:jk...@in...> >>>> *To:* Jimmy Zhang <mailto:cra...@co...> >>>> *Sent:* Thursday, November 30, 2006 12:34 AM >>>> *Subject:* RE: [Vtd-xml-users] Performance in comparison to libxml2 >>>> >>>> Jimmy, >>>> >>>> I ran the tests multiple times to include startup and shutdown >>>> processing. I could create a loop doing 50 to 100 tests if that's >>>> what you prefer (or like to see). >>>> >>>> Creating strings is the actual retrieving of node data; looks quite >>>> important to me.. >>>> >>>> -----Original Message----- >>>> From: Jimmy Zhang [mailto:cra...@co...] >>>> Sent: Thu 30-11-2006 4:22 >>>> To: John Kraal >>>> Cc: vtd...@li... >>>> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >>>> >>>> Benchmarks usualy iterate the test for a large numbers before >>>> taking the >>>> average >>>> for each iteration, this is especially important for Java because >>>> server JVM >>>> takes >>>> some iterations to warm up ... >>>> Also Is there a need for creating strings?? A smart work around may >>>> exist to >>>> completely >>>> bypass this stage... >>>> ----- Original Message ----- >>>> From: "John Kraal" <jk...@in...> >>>> To: "Jimmy Zhang" <cra...@co...> >>>> Sent: Tuesday, November 28, 2006 11:48 PM >>>> Subject: Re: [Vtd-xml-users] Performance in comparison to libxml2 >>>> >>>> >>>> > In order >>>> > >>>> > * I used 1.8; but indeed I should've tested the java-cvs as well. >>>> > * Test code included; jkl.files.xml is described somewhat >>>> earlier (137 >>>> > mb) and the other attached as well. >>>> > * Java 1.5 something, it's a pain to get that installed and >>>> uninstalled >>>> > on Debian (Debian mindset: Proprietary software is evil) >>>> > * Parsing is actually reading the file and making it workable; >>>> maybe >>>> > that just didn't change significantly? >>>> > * I really cannot explain.. I believe it is now about the same >>>> speed as >>>> > '//*' >>>> > >>>> > Jimmy Zhang wrote: >>>> >> looks interesting.. a few things >>>> >> >>>> >> * you should check out the latest java version for the testing >>>> as >>>> well >>>> >> since there has been changes >>>> >> * What are the test code and conditions? We are doing a bit of >>>> >> benchmarking >>>> >> ourselves, mostly with modest file sizes... >>>> >> >>>> >> * for java version ,did you use server JVM, that makes a hell of >>>> >> difference?? >>>> >> >>>> >> I read it a bit more, there are more questions than answers... >>>> >> * from vtd-xml-c to vtdxml 1.8 cvs, there is no change at all >>>> >> at the parsing code, why there is a big difference in >>>> performance? >>>> >> >>>> >> * how come //*[local-name()="Descriptor"] takes shorter amoutn >>>> >> of time than //* >>>> >> ----- Original Message ----- From: "John Kraal" >>>> <jk...@in...> >>>> >> To: "Jimmy Zhang" <cra...@co...> >>>> >> Sent: Tuesday, November 28, 2006 4:38 AM >>>> >> Subject: Re: [Vtd-xml-users] Performance in comparison to >>>> libxml2 >>>> >> >>>> >> >>>> >>> I've tested the CVS version and included the results I've >>>> recorded until >>>> >>> now. I'm actually a bit too lazy to build other java-parsers >>>> to test >>>> >>> with, but it indicates a little of the C performance. >>>> >>> >>>> >>> I'm interested in your opinion on this before continuing with >>>> testing.. >>>> >>> >>>> >>> Regards, >>>> >>> John >>>> >>> >>>> >>> Jimmy Zhang wrote: >>>> >>>> There has been some significant XPath eval performance >>>> enhancement >>>> >>>> slated >>>> >>>> for next release, if you want to give a try, it is also in CVS >>>> moments >>>> >>>> ago... >>>> >>>> ----- Original Message ----- From: "John Kraal" >>>> <jk...@in...> >>>> >>>> To: "Jimmy Zhang" <cra...@co...> >>>> >>>> Sent: Tuesday, November 21, 2006 12:38 AM >>>> >>>> Subject: Re: [Vtd-xml-users] Performance in comparison to >>>> libxml2 >>>> >>>> >>>> >>>> >>>> >>>>> What failed exactly? Anyway, I'll do what I can; just notify >>>> me when >>>> >>>>> you >>>> >>>>> release 1.8. >>>> >>>>> >>>> >>>>> regards, >>>> >>>>> John >>>> >>>>> >>>> >>>>> Jimmy Zhang wrote: >>>> >>>>>> John, I wasn't able to get the toolchain script to work? >>>> >>>>>> Can you help us create another tar.gz release after the >>>> release of >>>> >>>>>> 1.8 >>>> >>>>>> in a few days.. >>>> >>>>>> Jimmy >>>> >>>>>> ----- Original Message ----- From: "John Kraal" >>>> <jk...@in...> >>>> >>>>>> To: "Jimmy Zhang" <cra...@co...> >>>> >>>>>> Cc: <vtd...@li...> >>>> >>>>>> Sent: Tuesday, November 07, 2006 12:12 AM >>>> >>>>>> Subject: Re: [Vtd-xml-users] Performance in comparison to >>>> libxml2 >>>> >>>>>> >>>> >>>>>> >>>> >>>>>>> No, I'm sorry - the files I used to test contains data >>>> from my >>>> >>>>>>> employer; >>>> >>>>>>> I will not be the one to distribute that :-). But it's >>>> quite >>>> easy to >>>> >>>>>>> create a fairly simple xml file like mine; and test it. >>>> >>>>>>> >>>> >>>>>>> Remember that I'm not testing a Java application, but >>>> merely C. >>>> >>>>>>> >>>> >>>>>>> The sources are in the previous email. >>>> >>>>>>> >>>> >>>>>>> The structure is quite simple, and as I'm not able to >>>> create >>>> a XSD >>>> >>>>>>> schema from a XML File easily (not really sure with what), >>>> here the >>>> >>>>>>> structure at it's simplest, just add some elements: >>>> >>>>>>> >>>> >>>>>>> <shipments> >>>> >>>>>>> <shipment dosvlg="123" afd="abc123"> >>>> >>>>>>> <from>NLAMS</from> >>>> >>>>>>> <to>NLRTM</to> >>>> >>>>>>> <goods> >>>> >>>>>>> <goodsline> >>>> >>>>>>> <merknr>abc</merknr> >>>> >>>>>>> <col code="pl">12345</col> >>>> >>>>>>> </goodsline> >>>> >>>>>>> </goods> >>>> >>>>>>> <relations> >>>> >>>>>>> <relation srtnaw="123" tsroln="123" relnr="123" zoek="abc"> >>>> >>>>>>> <tsnam1>abc</tsnam1> >>>> >>>>>>> <coordinates> >>>> >>>>>>> <tscoox>-12.3456</tscoox> >>>> >>>>>>> <tscooy>-12.3456</tscoox> >>>> >>>>>>> </coordinates> >>>> >>>>>>> </relation> >>>> >>>>>>> </relations> >>>> >>>>>>> </shipment> >>>> >>>>>>> </shipments> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> Jimmy Zhang wrote: >>>> >>>>>>>> Can you provide a few sample XML files that you used for >>>> the >>>> >>>>>>>> testing? >>>> >>>>>>>> >>>> >>>>>>>> I am sure there can be additioal performance tuning for >>>> performance >>>> >>>>>>>> evaluation... >>>> >>>>>>>> >>>> >>>>>>>> So far the response we got compare VTD-XML favorably with >>>> Xerces... >>>> >>>>>>>> for the java version.. >>>> >>>>>>>> ----- Original Message ----- From: "John Kraal - Kewill >>>> >>>>>>>> Interchain NL" >>>> >>>>>>>> <jk...@in...> >>>> >>>>>>>> To: <vtd...@li...> >>>> >>>>>>>> Sent: Monday, November 06, 2006 4:23 AM >>>> >>>>>>>> Subject: [Vtd-xml-users] Performance in comparison to >>>> libxml2 >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>>> Hello, >>>> >>>>>>>>> >>>> >>>>>>>>> I've been playing with vtdxml for a while now, and my >>>> latest >>>> >>>>>>>>> experience >>>> >>>>>>>>> is not very encouraging to go on :(... >>>> >>>>>>>>> >>>> >>>>>>>>> I have created a file with _lots_ of recurring >>>> structures and >>>> >>>>>>>>> amounts of >>>> >>>>>>>>> recurring data (about 137 MB), eventually I created a >>>> xpath to >>>> >>>>>>>>> select >>>> >>>>>>>>> the name of every relation in the 4th role (doesn't >>>> really >>>> >>>>>>>>> matter). >>>> >>>>>>>>> >>>> >>>>>>>>> So, I executed it, with the code included for vtdxml (see >>>> >>>>>>>>> vtdxml.c), >>>> >>>>>>>>> and >>>> >>>>>>>>> it performed like this: >>>> >>>>>>>>> >>>> >>>>>>>>> unims@gxvm1:~/src/xmltest$ time ./test ./jkl.files.xml >>>> >>>>>>>>> '//relation[@tsroln=04]/tsnam1' >> /dev/null >>>> >>>>>>>>> >>>> >>>>>>>>> real 0m4.940s >>>> >>>>>>>>> user 0m4.625s >>>> >>>>>>>>> sys 0m0.256s >>>> >>>>>>>>> >>>> >>>>>>>>> With 162450 bytes of terminal output. >>>> >>>>>>>>> >>>> >>>>>>>>> Then, the horrible thing happened, I used lixml2 with an >>>> adjusted >>>> >>>>>>>>> reference xpath-program. (xpath1.c from their website, >>>> only with >>>> >>>>>>>>> content >>>> >>>>>>>>> retrieval): >>>> >>>>>>>>> >>>> >>>>>>>>> unims@gxvm1:~/src/libxmltest$ time ./test ./jkl.files.xml >>>> >>>>>>>>> '//relation[@tsroln=04]/tsnam1' >> /dev/null >>>> >>>>>>>>> >>>> >>>>>>>>> real 0m2.545s >>>> >>>>>>>>> user 0m2.201s >>>> >>>>>>>>> sys 0m0.321s >>>> >>>>>>>>> >>>> >>>>>>>>> The size of the output was 150808 bytes. >>>> >>>>>>>>> >>>> >>>>>>>>> This is an incredible difference, am I doing something >>>> wrong? Or >>>> >>>>>>>>> did I >>>> >>>>>>>>> have too many expectations of vtd? >>>> >>>>>>>>> >>>> >>>>>>>>> Regards, >>>> >>>>>>>>> John Kraal >>>> >>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> >>>>>>>>\ >>>> >>>>>>>>> >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> Using Tomcat but need to do more? Need to support web >>>> services, >>>> >>>>>>>>> security? >>>> >>>>>>>>> Get stuff done quickly with pre-integrated technology to >>>> make your >>>> >>>>>>>>> job >>>> >>>>>>>>> easier >>>> >>>>>>>>> Download IBM WebSphere Application Server v.1.0.1 based >>>> on >>>> Apache >>>> >>>>>>>>> Geronimo >>>> >>>>>>>>> >>>> >>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>>> >>>> <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642> >>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>> -------------------------------------------------------------------------------- >>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>>> _______________________________________________ >>>> >>>>>>>>> Vtd-xml-users mailing list >>>> >>>>>>>>> Vtd...@li... >>>> >>>>>>>>> >>>> https://lists.sourceforge.net/lists/listinfo/vtd-xml-users >>>> >>>>>>>>> >>>> >>>>>>>> >>>> >>>>>>>> >>>> >>>>>>> = >>>> >>> >> >> > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X