Menu
▾
▴
vtd-xml-users — This mailing list is for users or people interested in VTD-XML
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(6) |
Jul
(21) |
Aug
(40) |
Sep
(7) |
Oct
(41) |
Nov
(52) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(49) |
Feb
(37) |
Mar
(84) |
Apr
(11) |
May
(29) |
Jun
(9) |
Jul
(19) |
Aug
(9) |
Sep
(6) |
Oct
(5) |
Nov
(15) |
Dec
(3) |
| 2008 |
Jan
(7) |
Feb
(11) |
Mar
(25) |
Apr
(50) |
May
(7) |
Jun
(8) |
Jul
(10) |
Aug
(18) |
Sep
(1) |
Oct
(15) |
Nov
(1) |
Dec
(9) |
| 2009 |
Jan
(5) |
Feb
(2) |
Mar
(3) |
Apr
(5) |
May
(10) |
Jun
(4) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(15) |
Nov
(13) |
Dec
(6) |
| 2010 |
Jan
|
Feb
(3) |
Mar
(4) |
Apr
(6) |
May
|
Jun
(4) |
Jul
(12) |
Aug
(8) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2011 |
Jan
(19) |
Feb
(39) |
Mar
(28) |
Apr
(6) |
May
(7) |
Jun
(9) |
Jul
|
Aug
(1) |
Sep
|
Oct
(8) |
Nov
(3) |
Dec
(12) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
(3) |
Apr
(4) |
May
(4) |
Jun
(3) |
Jul
(10) |
Aug
(2) |
Sep
(13) |
Oct
(24) |
Nov
(3) |
Dec
(1) |
| 2013 |
Jan
(11) |
Feb
(5) |
Mar
(4) |
Apr
(3) |
May
(3) |
Jun
(5) |
Jul
(7) |
Aug
(16) |
Sep
|
Oct
(7) |
Nov
(11) |
Dec
|
| 2014 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(3) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
(11) |
May
(8) |
Jun
(3) |
Jul
(1) |
Aug
(3) |
Sep
(5) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(3) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(2) |
Jun
|
Jul
(4) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2019 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <Raj...@ba...> - 2007-10-12 03:19:57
|
Hi,=20 I just started working with VTD-XML . There are a couple of issues that's bothering me, I would appreciate if any of you could help me in resolving the same.=20 Scenario: I am processing xml files in order of 250mb, this is when I have compressed the tagnames form say <thisiselementname> to <c11>.=20 * First issue is I often run into OutOfMemory issue, setting -Xmx1024m resolved the issue but I fail to run this with Jprobe.=20 * The second issuehere is I want to change the column names back to the original column names as part of postprocessing ,=20 =20 but VDT-xml doesn't allow that, any work around for that. Or changes in the parser that I can make to do this.=20 Thanks and regards Khokher ------------------------------------------------------------------------ For important statutory and regulatory disclosures and more information a= bout Barclays Capital, please visit our web site at http://www.barcap.com= . Internet communications are not secure and therefore the Barclays Group d= oes not accept legal responsibility for the contents of this message. Al= though the Barclays Group operates anti-virus programmes, it does not acc= ept responsibility for any damage whatsoever that is caused by viruses be= ing passed. Any views or opinions presented are solely those of the auth= or and do not necessarily represent those of the Barclays Group. Replies= =20to this email may be monitored by the Barclays Group for operational o= r business reasons. Barclays Capital is the investment banking division of Barclays Bank PLC,= =20a company registered in England (number 1026167) with its registered o= ffice at 1 Churchill Place, London, E14 5HP. This email may relate to or = be sent from other members of the Barclays Group. ------------------------------------------------------------------------ |
|
From: Raju <gvr...@go...> - 2007-09-25 21:29:17
|
I was doing some string manipulation in my POC which is causing the issu= e.=0AIt works fine. Please ignore this issue.=0A=0AThanks,=0ARaju=0A=0A= =0A=0A-----Original Message-----=0AFrom: gvr...@go...=0ASent: Tue= sday, September 25, 2007 7:17 PM -07:00=0ATo: vtd...@li...= forge.net=0ASubject: [Vtd-xml-users] Error in parsing when attribute are= in new line=0A=0AHI,=0A=0AI am getting an exception when the attributes= are in new line in my XML file.=0A=0Amy XML,=0A=0A<root>=0A <child= =0A id=3D"myId">=0A SOme text=0A </child>=0A</r= oot>=0A=0AException,=0A=0Acom.ximpleware.ParseException: Starting tag= Error: Invalid char in starting tag=0A=0AIf I modify my xml to =0A=0A<r= oot>=0A <child id=3D"myId">=0A SOme text=0A </child>=0A<= /root>=0A=0Athen it is working fine.=0A=0AAs I can't controll the incomi= ng messages, I can't modify the xml.=0A=0AIs there a way to avoid this= problem?=0A=0AAppreciate your help.=0A=0AThanks,=0ARaju=0A=0A |
|
From: Raju G. <gvr...@go...> - 2007-09-25 19:18:00
|
HI,=0A=0AI am getting an exception when the attributes are in new line= in my XML file.=0A=0Amy XML,=0A=0A<root>=0A <child =0A = id=3D"myId">=0A SOme text=0A </child>=0A</root>=0A=0AExcep= tion,=0A=0Acom.ximpleware.ParseException: Starting tag Error: Invalid= char in starting tag=0A=0AIf I modify my xml to =0A=0A<root>=0A <chi= ld id=3D"myId">=0A SOme text=0A </child>=0A</root>=0A=0Athe= n it is working fine.=0A=0AAs I can't controll the incoming messages,= I can't modify the xml.=0A=0AIs there a way to avoid this problem?=0A= =0AAppreciate your help.=0A=0AThanks,=0ARaju=0A=0A |
|
From: jimmy Z. <cra...@co...> - 2007-09-19 07:33:59
|
I don't know delphi, but my experience implementing VTD-XML is that=20
inlining makes big differences, so does modularity,=20
can you profile your code in Delphi to see where the CPU cycles go?
2.4 Ghz p4 is pretty fast, I think you may refactor your code to =
achieve
better performance...
----- Original Message -----=20
From: jxjxhjp=20
To: jimmy Zhang=20
Sent: Tuesday, September 18, 2007 5:56 PM
Subject: Re:Re: [Vtd-xml-users] hi, I am a VTDXML's learner
I have rewrote VTD-XML entirely in delphi, maybe one of the reasons =
for not good perferance is that my computer configuration isn't =
Anthlon64 3400+ ^_^, just P4 2.4GHZ.but I think there should be other =
reasons.=20
=D4=DA2007-09-19=A3=AC"jimmy Zhang" <cra...@co...> =
=D0=B4=B5=C0=A3=BA
for your first question, did you rewrite VTD-XML entirely? Or simply =
create DLLs=20
and call them from Delphi?
for the seond question, l1, l2 and l3 level location cache are for =
random access,
currently, above 3, the navigation is by scan VTD records...
----- Original Message -----=20
From: jxjxhjp=20
To: vtd...@li...=20
Sent: Tuesday, September 18, 2007 3:49 AM
Subject: [Vtd-xml-users] hi, I am a VTDXML's learner
hi:
I have studied VTDXML for a long time(about 3 months), and now, =
there are some=20
questions on VTDXML for me, and I would like to get your help.
the questions are:
(1)I have implemented VTDXML in delphi roughly, and I have =
tested the performance of my=20
implement with some xml case(eg. =
32K=A1=A21.5M=A1=A23M=A1=A27M=A1=A220M=A1=A250M xml files=A3=ACsome of =
which=20
include Unicode string, and some of which are pure ASCII), =
following is the test Result:
(my computer configuration is CPU: P4 2.4GHZ, Memory: 1GB)
file size(M) parse(s) Nav all =
elements(no Attr)(s)
50M 7.8 3.5
20M 3.44 1.6
7M 1.28 2
3M 0.547 0.125
1.5M 0.329 0.438
32K 0.11 ~0 =20
from above, we could compute that the throughput is between =
5.5M~6.6MB/Sec during VTD=20
Parsing. when I got the Result of my exe's performance, I have =
some disappointment, and=20
my question is whether the result is in normal range of VTD's =
performance. I have got=20
the normal range of VTD's performance from VTDXML Home =
Page(http://vtd-
xml.sourceforge.net/) which is 50~60 MB/sec sustained throughput, =
so the discrepancy is 9=20
multiple, I can't believe it! up to now, I am still finding the =
reasons!
(2)In the source code unit of VTDGen, we can find the class VTDGen =
have three private property(L1Buffer, L2Buffer, L3Buffer), my question =
is what is the accurate meaning of those. my comprehension for those is =
(1)first of all, they are designed to record LCs,YES? (2)secondly, as =
far as I know, L1Buffer is used for recording LCs when element depth =
equals just 1, accordingly, L2Buffer record LCs when element depth =
equals just 2,YES?(3)L3Buffer is used for doing what?(4)those property =
just record LCs when depth equals 1 or 2 ,or maybe 3. I want to know who =
record LCs when depth is greater than 3, such as 4,5,6....and why is =
Designed like this?
so far, mainly the two questions above puzzle me, I would like =
to receive you answers sincerely!
=
Yours!
=
2007.9.18
-------------------------------------------------------------------------=
-
=B5=E3 =BB=F7 =B4=CB =B4=A6=A3=A1=C3=E2 =B7=D1 =CA=D4 =CD=E6 07 =
=C4=EA =D7=EE =CA=DC =C6=DA =B4=FD =B5=C4 =D3=CE =CF=B7 =B4=F3 =D7=F7 =
=A3=A1=20
-------------------------------------------------------------------------=
-
=
-------------------------------------------------------------------------=
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/=20
-------------------------------------------------------------------------=
-
_______________________________________________
Vtd-xml-users mailing list
Vtd...@li...
https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
-------------------------------------------------------------------------=
-----
=C4=E3 =CD=E6 =B9=FD 07 =C4=EA =D7=EE =BB=F0 =B1=AC =B5=C4 =CD=F8 =
=D3=CE =C2=F0 =A3=BF=BB=B9 =C3=BB =D3=D0 =A3=BF=A3=A1=B5=E3 =D5=E2 =
=C0=EF=A3=AC=B5=E3 =D5=E2 =C0=EF >> |
|
From: jimmy Z. <cra...@co...> - 2007-09-18 19:24:21
|
for your first question, did you rewrite VTD-XML entirely? Or simply =
create DLLs=20
and call them from Delphi?
for the seond question, l1, l2 and l3 level location cache are for =
random access,
currently, above 3, the navigation is by scan VTD records...
----- Original Message -----=20
From: jxjxhjp=20
To: vtd...@li...=20
Sent: Tuesday, September 18, 2007 3:49 AM
Subject: [Vtd-xml-users] hi, I am a VTDXML's learner
hi:
I have studied VTDXML for a long time(about 3 months), and now, =
there are some=20
questions on VTDXML for me, and I would like to get your help.
the questions are:
(1)I have implemented VTDXML in delphi roughly, and I have tested =
the performance of my=20
implement with some xml case(eg. =
32K=A1=A21.5M=A1=A23M=A1=A27M=A1=A220M=A1=A250M xml files=A3=ACsome of =
which=20
include Unicode string, and some of which are pure ASCII), following =
is the test Result:
(my computer configuration is CPU: P4 2.4GHZ, Memory: 1GB)
file size(M) parse(s) Nav all elements(no =
Attr)(s)
50M 7.8 3.5
20M 3.44 1.6
7M 1.28 2
3M 0.547 0.125
1.5M 0.329 0.438
32K 0.11 ~0 =20
from above, we could compute that the throughput is between =
5.5M~6.6MB/Sec during VTD=20
Parsing. when I got the Result of my exe's performance, I have some =
disappointment, and=20
my question is whether the result is in normal range of VTD's =
performance. I have got=20
the normal range of VTD's performance from VTDXML Home =
Page(http://vtd-
xml.sourceforge.net/) which is 50~60 MB/sec sustained throughput, so =
the discrepancy is 9=20
multiple, I can't believe it! up to now, I am still finding the =
reasons!
(2)In the source code unit of VTDGen, we can find the class VTDGen =
have three private property(L1Buffer, L2Buffer, L3Buffer), my question =
is what is the accurate meaning of those. my comprehension for those is =
(1)first of all, they are designed to record LCs,YES? (2)secondly, as =
far as I know, L1Buffer is used for recording LCs when element depth =
equals just 1, accordingly, L2Buffer record LCs when element depth =
equals just 2,YES?(3)L3Buffer is used for doing what?(4)those property =
just record LCs when depth equals 1 or 2 ,or maybe 3. I want to know who =
record LCs when depth is greater than 3, such as 4,5,6....and why is =
Designed like this?
so far, mainly the two questions above puzzle me, I would like to =
receive you answers sincerely!
Yours!
2007.9.18
-------------------------------------------------------------------------=
-----
=B5=E3 =BB=F7 =B4=CB =B4=A6=A3=A1=C3=E2 =B7=D1 =CA=D4 =CD=E6 07 =C4=EA =
=D7=EE =CA=DC =C6=DA =B4=FD =B5=C4 =D3=CE =CF=B7 =B4=F3 =D7=F7 =A3=A1=20
-------------------------------------------------------------------------=
-----
=
-------------------------------------------------------------------------=
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
-------------------------------------------------------------------------=
-----
_______________________________________________
Vtd-xml-users mailing list
Vtd...@li...
https://lists.sourceforge.net/lists/listinfo/vtd-xml-users
|
|
From: jxjxhjp <jx...@16...> - 2007-09-18 10:49:26
|
hi:
I have studied VTDXML for a long time(about 3 months), and now, there are=
somequestions on VTDXML for me, and I would like to get your help.
the questions are:
(1)I have implemented VTDXML in delphi roughly, and I have tested the per=
formance of myimplement with some xml case(eg. 32K=A1=A21.5M=A1=A23M=A1=A27=
M=A1=A220M=A1=A250M xml files=A3=ACsome of whichinclude Unicode string, and=
some of which are pure ASCII), following is the test Result:
(my computer configuration is CPU: P4 2.4GHZ, Memory: 1GB)
file size(M) parse(s) Nav all elements(no Attr)(=
s)
50M 7.8 3.5
20M 3.44 1.6
7M 1.28 2
3M 0.547 0.125
1.5M 0.329 0.438
32K 0.11 ~0 from above, we coul=
d compute that the throughput is between 5.5M~6.6MB/Sec during VTDParsing. =
when I got the Result of my exe's performance, I have some disappointment, =
andmy question is whether the result is in normal range of VTD's performan=
ce. I have gotthe normal range of VTD's performance from VTDXML Home Page(h=
ttp://vtd-xml.sourceforge.net/) which is 50~60 MB/sec sustained throughput,=
so the discrepancy is 9multiple, I can't believe it! up to now, I am still=
finding the reasons!(2)In the source code unit of VTDGen, we can find the =
class VTDGen have three private property(L1Buffer, L2Buffer, L3Buffer), my =
question is what is the accurate meaning of those. my comprehension for tho=
se is (1)first of all, they are designed to record LCs,YES? (2)secondly, as=
far as I know, L1Buffer is used for recording LCs when element depth equal=
s just 1, accordingly, L2Buffer record LCs when element depth equals just 2=
,YES?(3)L3Buffer is used for doing what?(4)those property just record LCs w=
hen depth equals 1 or 2 ,or maybe 3. I want to know who record LCs when dep=
th is greater than 3, such as 4,5,6....and why is Designed like this? so f=
ar, mainly the two questions above puzzle me, I would like to receive you a=
nswers sincerely!
Yours!
2007.9.18 |
|
From: jimmy Z. <cra...@co...> - 2007-09-10 20:07:41
|
OnJava http://www.onjava.com/pub/a/onjava/2007/09/07/schema-less-java-xml-data-b= inding-with-vtd-xml.html |
|
From: jimmy Z. <cra...@co...> - 2007-08-30 20:38:13
|
Right now, VTD-XML's tutorial are spreaded in a number of articles which you can find in the "links and presentations section." But those articles are mostly for Java ... The C version of VTD-XML is created in a way that retains most of the looks, feels and styles of Java, so if you want to write in C version, I suggest that you starts with those Java article... We have been contacted by open source training companies asking us to create training materials ... so expect more training materials on VTD-XML project site... Writing books may be a good idea after VTD-XML gets more complete in features/functionalities... ----- Original Message ----- From: "Rob Larkins" <rla...@pt...> To: "VTD-XML ML" <vtd...@li...> Sent: Thursday, August 30, 2007 12:53 PM Subject: [Vtd-xml-users] Are there any books on VTD-XML? > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Are there any reference books on VTD-XML, or are there any books in the > process of being written? > > I'm interested in VTD-XML, but I'm hesitant to start with it because I > can't > find any good reference books. Particularly because I want to use the C > port. There are oodles of books on DOM and SAX, but nothing for VTD-XML I > can find. > > - -Rob > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > > iD8DBQFG1x89+KyO/KUp2FYRAoVxAKDkqNWTcH3aR6FBnszx9MjtPrg0eACghBo+ > RKjN2ntrx7gOM8GZksr1WIE= > =1ZuH > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > |
|
From: Rob L. <rla...@pt...> - 2007-08-30 20:00:15
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Are there any reference books on VTD-XML, or are there any books in the process of being written? I'm interested in VTD-XML, but I'm hesitant to start with it because I can't find any good reference books. Particularly because I want to use the C port. There are oodles of books on DOM and SAX, but nothing for VTD-XML I can find. - -Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFG1x89+KyO/KUp2FYRAoVxAKDkqNWTcH3aR6FBnszx9MjtPrg0eACghBo+ RKjN2ntrx7gOM8GZksr1WIE= =1ZuH -----END PGP SIGNATURE----- |
|
From: jimmy Z. <cra...@co...> - 2007-08-29 07:39:29
|
Hi, All, I am posting this for Duane May who is working on extending VTD for 64-bit JVM supporting a maximum 64GB document size... Thanks, Jimmy I am looking for feedback on the following VTD record bit usage. This will support documents up to 64GB... Token Starting offset: 36bits (68,719,476,735) QName Length: 11bits (2,047) Prefix Length: 7bits (127 originally 511) Nesting Depth: 6bits (63 originally 255) Token Type: 4bits (15) Reserved Bits: 0 (0 originally 4) |
|
From: <cra...@co...> - 2007-08-13 06:46:18
|
Do those users actually create class files from the schema? Would it be feasible to publish only the binding info in the form of XPath expressions? -------------- Original message -------------- From: Mark Swanson <ma...@Sc...> > > Just a thought: it doesn't really free me completely from XML Schema in > the sense that I still need to publish the Schema so clients know how to > speak to my service. It does free folks from a lot of the garbage > XML-Java mapping tools out there. > > 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. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users |
|
From: Mark S. <ma...@Sc...> - 2007-08-12 23:51:29
|
Just a thought: it doesn't really free me completely from XML Schema in the sense that I still need to publish the Schema so clients know how to speak to my service. It does free folks from a lot of the garbage XML-Java mapping tools out there. 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...> - 2007-08-12 17:59:49
|
test post |
|
From: jie y. <leo...@gm...> - 2007-08-12 04:05:45
|
Hi, All, an article of using VTD-XML to achieve schemaless data bind in Java <http://docs.google.com/Doc?id=dhdt7pxf_28dp3d8v> http://docs.google.com/Doc?id=dhdt7pxf_28dp3d8v Cheers, Jimmy |
|
From: ZhangQian <zha...@ne...> - 2007-08-08 08:43:37
|
Hi All, How progress xml on chip? I want to know whether VTD-XML based on FPGA has been realized.Thanks. ---------------------------------------------------------------------------------------------- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Group Ltd., its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful. If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. ----------------------------------------------------------------------------------------------- |
|
From: jie y. <leo...@gm...> - 2007-08-02 12:47:17
|
Hi all, I've added several geo-functions on the basis of existing xpath implementation of VTD-XML, and found out that it's much more efficient than the similar implementation based on Xalan. But, there're still some headachy issues. First of all, version control of geoxpath is disconnected with VTD-XML, I checked out VTD-XML 2.0, modified and appended, then checked in as geoxpath, it's a bit confused. Second, I found out it's quite difficult to implement such functions that create nodeset output, index value returned alone is meaningless without the new VTDGen/VTDNav context. Jimmy or someone else have some ideas? |
|
From: Sun, V. <vs...@am...> - 2007-07-06 04:12:52
|
Each stage has its own xpath, they don't change due to the invocation sequence. Basically stages don't know who is executed prior or after. And yes the xpath will see the result the previous stage updated, if any. For the price-info stage, it will always run the xpath to look for product-id, disregard if it is the first stage or the 3rd stage. =20 Hope this helps. -------------------------- Cheers, Vanessa -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...]=20 Sent: Thursday, July 05, 2007 7:52 PM To: Sun, Vanessa Cc: vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? For those two use cases, do subsequent stages run different XPath over resultant DOM tree which the previous stage updates? ----- Original Message ----- From: "Sun, Vanessa" <vs...@am...> To: "Jimmy Zhang" <cra...@co...> Cc: <vtd...@li...> Sent: Wednesday, July 04, 2007 1:59 PM Subject: RE: [Vtd-xml-users] update-operation impact, if any? > are X and Y threads? Not really, consider them are just business logic components (class), let's just say they are running in the same thread to simplify this discussion. > so XML flows in, XML converts into DOM tree, performs random logic, then passes it to Y. Y does something then generates output XML.. Yes, sort of, except there might many X before Y, so many tree updates before the final serialization: For example: Usecase 1: give me the all product info where product-name =3D "abc" stage1 (adding seller) -> stage2 (adding product id) -> stage3 (adding price) -> stage4 (serialize output). Usecase 2: give me the price info where product-id =3D "123" and seller=3D"xyz" stage2 (adding price) -> stage3 (serialize output). *Each of the "()" represent a business logic unit. To retrieve price, we need to know product-id and seller. -------------------------- Cheers, Vanessa -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...] Sent: Wednesday, July 04, 2007 1:59 AM To: Sun, Vanessa Cc: vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? are X and Y threads? so XML flows in, XML converts into DOM tree, performs random logic, then passes it to Y. Y does something then generates output XML.. did I get the use case roughly right? ----- Original Message ----- From: "Sun, Vanessa" <vs...@am...> To: "Jimmy Zhang" <cra...@co...>; "Tatu Saloranta" <cow...@ya...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 6:47 PM Subject: RE: [Vtd-xml-users] update-operation impact, if any? For one, we do xpath, if the data is not in the tree, it won't show up in the query result. Two, the sequence of the stage is dynamic, so the data could be populated by X for this request, and by Y for next request, or sometimes the dom came in with the data already filled in. In order to prevent each stage checking for all possible sources, we decided that everybody will just put the result into the dom tree, i.e. the tree is the centralized data bus flowing through the pipeline collecting data as it goes. P.S. Yes the use case is a in-memory pipeline. -------------------------- Cheers, Vanessa -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...] Sent: Tuesday, July 03, 2007 12:23 PM To: Tatu Saloranta; Sun, Vanessa; vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? If the processing takes place in the same process space, then if the goal is to make changes to XML payload, then would it be possible to put the "changes" in a seperate structure? there may not be a need to store the changes in XML itself you don't really have to put something in XML just to read it back out again, why not just accessing the info directly? ----- Original Message ----- From: "Tatu Saloranta" <cow...@ya...> To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" <vs...@am...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 8:19 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? > Yes, I am assuming this since the original question definitely sounded > like it was an in-process modification -- otherwise it wouldn't have > made sense. > > It is true of course that when travelling over the network, process > boundaries etc, some serialization is needed. > > -+ Tatu +- > > ----- Original Message ---- > From: Jimmy Zhang <cra...@co...> > To: Tatu Saloranta <cow...@ya...>; "Sun, Vanessa" > <vs...@am...>; vtd...@li... > Sent: Monday, July 2, 2007 10:34:25 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > Ok, I think the assumption here is that everything happens within a > single process... > but pipelining usually is more broadly defined as passing XML data > across process's boundry (even across the network, e.g. SOA > components) between mutiple programs... like unix's IPC, in that case, > it is usually not possible to pass a DOM tree around without re-serializing... > > ----- Original Message ----- > From: "Tatu Saloranta" <cow...@ya...> > To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" > <vs...@am...>; > <vtd...@li...> > Sent: Monday, July 02, 2007 9:45 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > >> --- Jimmy Zhang <cra...@co...> wrote: >> >>> It is not much different from DOM, albeit VTD-XML's more >>> efficient... >>> when you send DOM downstream, still need to serialize... >>> for VTD-XML, you just call XMLModifier's output()... >> >> Not necessarily, more often it's all within a single process, the >> tree model just gets passed. If so, no additional serialization or >> parsing is needed. >> >> I think it is fair to say that different models are more optimal for >> different use cases, and that heavy modifications are amongst hardest >> use cases for extractive parsers to implement efficiently (as opposed >> to read-only that is the most optimal). >> >> Regarding original problem -- it is of course possible to move from >> basic DOM to other Java tree alternatives. Also, most xml processing >> overhead might not come directly from DOM model itself: it is good to >> profile to see if it might have to do with other processing (xslt if >> it's being used, xpath, naive business logic that uses too much >> traversal). >> >> -+ Tatu +- >> >> >> >> >> _____________________________________________________________________ >> _______________ Sick sense of humor? Visit Yahoo! TV's Comedy with an >> Edge to see what's on, when. >> http://tv.yahoo.com/collections/222 >> > > > > ---------------------------------------------------------------------- > --- This SF.net email is sponsored by DB2 Express Download DB2 Express > C - the FREE version of DB2 express and take control of your XML. No > limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > > > > > > > ______________________________________________________________________ > ______________Ready > for the edge of your seat? > Check out tonight's top picks on Yahoo! TV. > http://tv.yahoo.com/ > |
|
From: Jimmy Z. <cra...@co...> - 2007-07-06 02:52:02
|
For those two use cases, do subsequent stages run different XPath over resultant DOM tree which the previous stage updates? ----- Original Message ----- From: "Sun, Vanessa" <vs...@am...> To: "Jimmy Zhang" <cra...@co...> Cc: <vtd...@li...> Sent: Wednesday, July 04, 2007 1:59 PM Subject: RE: [Vtd-xml-users] update-operation impact, if any? > are X and Y threads? Not really, consider them are just business logic components (class), let's just say they are running in the same thread to simplify this discussion. > so XML flows in, XML converts into DOM tree, performs random logic, then passes it to Y. Y does something then generates output XML.. Yes, sort of, except there might many X before Y, so many tree updates before the final serialization: For example: Usecase 1: give me the all product info where product-name = "abc" stage1 (adding seller) -> stage2 (adding product id) -> stage3 (adding price) -> stage4 (serialize output). Usecase 2: give me the price info where product-id = "123" and seller="xyz" stage2 (adding price) -> stage3 (serialize output). *Each of the "()" represent a business logic unit. To retrieve price, we need to know product-id and seller. -------------------------- Cheers, Vanessa -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...] Sent: Wednesday, July 04, 2007 1:59 AM To: Sun, Vanessa Cc: vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? are X and Y threads? so XML flows in, XML converts into DOM tree, performs random logic, then passes it to Y. Y does something then generates output XML.. did I get the use case roughly right? ----- Original Message ----- From: "Sun, Vanessa" <vs...@am...> To: "Jimmy Zhang" <cra...@co...>; "Tatu Saloranta" <cow...@ya...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 6:47 PM Subject: RE: [Vtd-xml-users] update-operation impact, if any? For one, we do xpath, if the data is not in the tree, it won't show up in the query result. Two, the sequence of the stage is dynamic, so the data could be populated by X for this request, and by Y for next request, or sometimes the dom came in with the data already filled in. In order to prevent each stage checking for all possible sources, we decided that everybody will just put the result into the dom tree, i.e. the tree is the centralized data bus flowing through the pipeline collecting data as it goes. P.S. Yes the use case is a in-memory pipeline. -------------------------- Cheers, Vanessa -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...] Sent: Tuesday, July 03, 2007 12:23 PM To: Tatu Saloranta; Sun, Vanessa; vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? If the processing takes place in the same process space, then if the goal is to make changes to XML payload, then would it be possible to put the "changes" in a seperate structure? there may not be a need to store the changes in XML itself you don't really have to put something in XML just to read it back out again, why not just accessing the info directly? ----- Original Message ----- From: "Tatu Saloranta" <cow...@ya...> To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" <vs...@am...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 8:19 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? > Yes, I am assuming this since the original question definitely sounded > like it was an in-process modification -- otherwise it wouldn't have > made sense. > > It is true of course that when travelling over the network, process > boundaries etc, some serialization is needed. > > -+ Tatu +- > > ----- Original Message ---- > From: Jimmy Zhang <cra...@co...> > To: Tatu Saloranta <cow...@ya...>; "Sun, Vanessa" > <vs...@am...>; vtd...@li... > Sent: Monday, July 2, 2007 10:34:25 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > Ok, I think the assumption here is that everything happens within a > single process... > but pipelining usually is more broadly defined as passing XML data > across process's boundry (even across the network, e.g. SOA > components) between mutiple programs... like unix's IPC, in that case, > it is usually not possible to pass a DOM tree around without re-serializing... > > ----- Original Message ----- > From: "Tatu Saloranta" <cow...@ya...> > To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" > <vs...@am...>; > <vtd...@li...> > Sent: Monday, July 02, 2007 9:45 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > >> --- Jimmy Zhang <cra...@co...> wrote: >> >>> It is not much different from DOM, albeit VTD-XML's more >>> efficient... >>> when you send DOM downstream, still need to serialize... >>> for VTD-XML, you just call XMLModifier's output()... >> >> Not necessarily, more often it's all within a single process, the >> tree model just gets passed. If so, no additional serialization or >> parsing is needed. >> >> I think it is fair to say that different models are more optimal for >> different use cases, and that heavy modifications are amongst hardest >> use cases for extractive parsers to implement efficiently (as opposed >> to read-only that is the most optimal). >> >> Regarding original problem -- it is of course possible to move from >> basic DOM to other Java tree alternatives. Also, most xml processing >> overhead might not come directly from DOM model itself: it is good to >> profile to see if it might have to do with other processing (xslt if >> it's being used, xpath, naive business logic that uses too much >> traversal). >> >> -+ Tatu +- >> >> >> >> >> _____________________________________________________________________ >> _______________ Sick sense of humor? Visit Yahoo! TV's Comedy with an >> Edge to see what's on, when. >> http://tv.yahoo.com/collections/222 >> > > > > ---------------------------------------------------------------------- > --- This SF.net email is sponsored by DB2 Express Download DB2 Express > C - the FREE version of DB2 express and take control of your XML. No > limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > > > > > > > ______________________________________________________________________ > ______________Ready > for the edge of your seat? > Check out tonight's top picks on Yahoo! TV. > http://tv.yahoo.com/ > |
|
From: Sun, V. <vs...@am...> - 2007-07-04 21:05:50
|
> are X and Y threads? Not really, consider them are just business logic components (class), let's just say they are running in the same thread to simplify this discussion. > so XML flows in, XML converts into DOM tree, performs random logic, then passes it to Y. Y does something then generates output XML.. Yes, sort of, except there might many X before Y, so many tree updates before the final serialization: For example:=20 Usecase 1: give me the all product info where product-name =3D "abc" stage1 (adding seller) -> stage2 (adding product id) -> stage3 (adding price) -> stage4 (serialize output). Usecase 2: give me the price info where product-id =3D "123" and seller=3D"xyz" stage2 (adding price) -> stage3 (serialize output). *Each of the "()" represent a business logic unit. To retrieve price, we need to know product-id and seller.=20 -------------------------- Cheers, Vanessa -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...]=20 Sent: Wednesday, July 04, 2007 1:59 AM To: Sun, Vanessa Cc: vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? are X and Y threads? so XML flows in, XML converts into DOM tree, performs random logic, then passes it to Y. Y does something then generates output XML.. did I get the use case roughly right? ----- Original Message ----- From: "Sun, Vanessa" <vs...@am...> To: "Jimmy Zhang" <cra...@co...>; "Tatu Saloranta"=20 <cow...@ya...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 6:47 PM Subject: RE: [Vtd-xml-users] update-operation impact, if any? For one, we do xpath, if the data is not in the tree, it won't show up in the query result. Two, the sequence of the stage is dynamic, so the data could be populated by X for this request, and by Y for next request, or sometimes the dom came in with the data already filled in. In order to prevent each stage checking for all possible sources, we decided that everybody will just put the result into the dom tree, i.e. the tree is the centralized data bus flowing through the pipeline collecting data as it goes. P.S. Yes the use case is a in-memory pipeline. -------------------------- Cheers, Vanessa -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...] Sent: Tuesday, July 03, 2007 12:23 PM To: Tatu Saloranta; Sun, Vanessa; vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? If the processing takes place in the same process space, then if the goal is to make changes to XML payload, then would it be possible to put the "changes" in a seperate structure? there may not be a need to store the changes in XML itself you don't really have to put something in XML just to read it back out again, why not just accessing the info directly? ----- Original Message ----- From: "Tatu Saloranta" <cow...@ya...> To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" <vs...@am...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 8:19 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? > Yes, I am assuming this since the original question definitely sounded > like it was an in-process modification -- otherwise it wouldn't have > made sense. > > It is true of course that when travelling over the network, process > boundaries etc, some serialization is needed. > > -+ Tatu +- > > ----- Original Message ---- > From: Jimmy Zhang <cra...@co...> > To: Tatu Saloranta <cow...@ya...>; "Sun, Vanessa" > <vs...@am...>; vtd...@li... > Sent: Monday, July 2, 2007 10:34:25 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > Ok, I think the assumption here is that everything happens within a > single process... > but pipelining usually is more broadly defined as passing XML data > across process's boundry (even across the network, e.g. SOA > components) between mutiple programs... like unix's IPC, in that case, > it is usually not possible to pass a DOM tree around without re-serializing... > > ----- Original Message ----- > From: "Tatu Saloranta" <cow...@ya...> > To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" > <vs...@am...>; > <vtd...@li...> > Sent: Monday, July 02, 2007 9:45 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > >> --- Jimmy Zhang <cra...@co...> wrote: >> >>> It is not much different from DOM, albeit VTD-XML's more >>> efficient... >>> when you send DOM downstream, still need to serialize... >>> for VTD-XML, you just call XMLModifier's output()... >> >> Not necessarily, more often it's all within a single process, the >> tree model just gets passed. If so, no additional serialization or >> parsing is needed. >> >> I think it is fair to say that different models are more optimal for >> different use cases, and that heavy modifications are amongst hardest >> use cases for extractive parsers to implement efficiently (as opposed >> to read-only that is the most optimal). >> >> Regarding original problem -- it is of course possible to move from >> basic DOM to other Java tree alternatives. Also, most xml processing >> overhead might not come directly from DOM model itself: it is good to >> profile to see if it might have to do with other processing (xslt if >> it's being used, xpath, naive business logic that uses too much >> traversal). >> >> -+ Tatu +- >> >> >> >> >> _____________________________________________________________________ >> _______________ Sick sense of humor? Visit Yahoo! TV's Comedy with an >> Edge to see what's on, when. >> http://tv.yahoo.com/collections/222 >> > > > > ---------------------------------------------------------------------- > --- This SF.net email is sponsored by DB2 Express Download DB2 Express > C - the FREE version of DB2 express and take control of your XML. No > limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > > > > > > > ______________________________________________________________________ > ______________Ready > for the edge of your seat? > Check out tonight's top picks on Yahoo! TV. > http://tv.yahoo.com/ > |
|
From: Jimmy Z. <cra...@co...> - 2007-07-04 08:59:56
|
are X and Y threads? so XML flows in, XML converts into DOM tree, performs random logic, then passes it to Y. Y does something then generates output XML.. did I get the use case roughly right? ----- Original Message ----- From: "Sun, Vanessa" <vs...@am...> To: "Jimmy Zhang" <cra...@co...>; "Tatu Saloranta" <cow...@ya...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 6:47 PM Subject: RE: [Vtd-xml-users] update-operation impact, if any? For one, we do xpath, if the data is not in the tree, it won't show up in the query result. Two, the sequence of the stage is dynamic, so the data could be populated by X for this request, and by Y for next request, or sometimes the dom came in with the data already filled in. In order to prevent each stage checking for all possible sources, we decided that everybody will just put the result into the dom tree, i.e. the tree is the centralized data bus flowing through the pipeline collecting data as it goes. P.S. Yes the use case is a in-memory pipeline. -------------------------- Cheers, Vanessa -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...] Sent: Tuesday, July 03, 2007 12:23 PM To: Tatu Saloranta; Sun, Vanessa; vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? If the processing takes place in the same process space, then if the goal is to make changes to XML payload, then would it be possible to put the "changes" in a seperate structure? there may not be a need to store the changes in XML itself you don't really have to put something in XML just to read it back out again, why not just accessing the info directly? ----- Original Message ----- From: "Tatu Saloranta" <cow...@ya...> To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" <vs...@am...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 8:19 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? > Yes, I am assuming this since the original question definitely sounded > like it was an in-process modification -- otherwise it wouldn't have > made sense. > > It is true of course that when travelling over the network, process > boundaries etc, some serialization is needed. > > -+ Tatu +- > > ----- Original Message ---- > From: Jimmy Zhang <cra...@co...> > To: Tatu Saloranta <cow...@ya...>; "Sun, Vanessa" > <vs...@am...>; vtd...@li... > Sent: Monday, July 2, 2007 10:34:25 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > Ok, I think the assumption here is that everything happens within a > single process... > but pipelining usually is more broadly defined as passing XML data > across process's boundry (even across the network, e.g. SOA > components) between mutiple programs... like unix's IPC, in that case, > it is usually not possible to pass a DOM tree around without re-serializing... > > ----- Original Message ----- > From: "Tatu Saloranta" <cow...@ya...> > To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" > <vs...@am...>; > <vtd...@li...> > Sent: Monday, July 02, 2007 9:45 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > >> --- Jimmy Zhang <cra...@co...> wrote: >> >>> It is not much different from DOM, albeit VTD-XML's more >>> efficient... >>> when you send DOM downstream, still need to serialize... >>> for VTD-XML, you just call XMLModifier's output()... >> >> Not necessarily, more often it's all within a single process, the >> tree model just gets passed. If so, no additional serialization or >> parsing is needed. >> >> I think it is fair to say that different models are more optimal for >> different use cases, and that heavy modifications are amongst hardest >> use cases for extractive parsers to implement efficiently (as opposed >> to read-only that is the most optimal). >> >> Regarding original problem -- it is of course possible to move from >> basic DOM to other Java tree alternatives. Also, most xml processing >> overhead might not come directly from DOM model itself: it is good to >> profile to see if it might have to do with other processing (xslt if >> it's being used, xpath, naive business logic that uses too much >> traversal). >> >> -+ Tatu +- >> >> >> >> >> _____________________________________________________________________ >> _______________ Sick sense of humor? Visit Yahoo! TV's Comedy with an >> Edge to see what's on, when. >> http://tv.yahoo.com/collections/222 >> > > > > ---------------------------------------------------------------------- > --- This SF.net email is sponsored by DB2 Express Download DB2 Express > C - the FREE version of DB2 express and take control of your XML. No > limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > > > > > > > ______________________________________________________________________ > ______________Ready > for the edge of your seat? > Check out tonight's top picks on Yahoo! TV. > http://tv.yahoo.com/ > |
|
From: Sun, V. <vs...@am...> - 2007-07-04 01:47:37
|
For one, we do xpath, if the data is not in the tree, it won't show up in the query result.=20 Two, the sequence of the stage is dynamic, so the data could be populated by X for this request, and by Y for next request, or sometimes the dom came in with the data already filled in. In order to prevent each stage checking for all possible sources, we decided that everybody will just put the result into the dom tree, i.e. the tree is the centralized data bus flowing through the pipeline collecting data as it goes. P.S. Yes the use case is a in-memory pipeline. -------------------------- Cheers, Vanessa -----Original Message----- From: Jimmy Zhang [mailto:cra...@co...]=20 Sent: Tuesday, July 03, 2007 12:23 PM To: Tatu Saloranta; Sun, Vanessa; vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? If the processing takes place in the same process space, then if the goal is to make changes to XML payload, then would it be possible to put the "changes" in a seperate structure? there may not be a need to store the changes in XML itself you don't really have to put something in XML just to read it back out again, why not just accessing the info directly? ----- Original Message ----- From: "Tatu Saloranta" <cow...@ya...> To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" <vs...@am...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 8:19 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? > Yes, I am assuming this since the original question definitely sounded > like it was an in-process modification -- otherwise it wouldn't have=20 > made sense. > > It is true of course that when travelling over the network, process=20 > boundaries etc, some serialization is needed. > > -+ Tatu +- > > ----- Original Message ---- > From: Jimmy Zhang <cra...@co...> > To: Tatu Saloranta <cow...@ya...>; "Sun, Vanessa"=20 > <vs...@am...>; vtd...@li... > Sent: Monday, July 2, 2007 10:34:25 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > Ok, I think the assumption here is that everything happens within a=20 > single process... > but pipelining usually is more broadly defined as passing XML data=20 > across process's boundry (even across the network, e.g. SOA=20 > components) between mutiple programs... like unix's IPC, in that case, > it is usually not possible to pass a DOM tree around without re-serializing... > > ----- Original Message ----- > From: "Tatu Saloranta" <cow...@ya...> > To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa"=20 > <vs...@am...>; > <vtd...@li...> > Sent: Monday, July 02, 2007 9:45 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > >> --- Jimmy Zhang <cra...@co...> wrote: >> >>> It is not much different from DOM, albeit VTD-XML's more=20 >>> efficient... >>> when you send DOM downstream, still need to serialize... >>> for VTD-XML, you just call XMLModifier's output()... >> >> Not necessarily, more often it's all within a single process, the=20 >> tree model just gets passed. If so, no additional serialization or=20 >> parsing is needed. >> >> I think it is fair to say that different models are more optimal for=20 >> different use cases, and that heavy modifications are amongst hardest >> use cases for extractive parsers to implement efficiently (as opposed >> to read-only that is the most optimal). >> >> Regarding original problem -- it is of course possible to move from=20 >> basic DOM to other Java tree alternatives. Also, most xml processing=20 >> overhead might not come directly from DOM model itself: it is good to >> profile to see if it might have to do with other processing (xslt if=20 >> it's being used, xpath, naive business logic that uses too much=20 >> traversal). >> >> -+ Tatu +- >> >> >> >> >> _____________________________________________________________________ >> _______________ Sick sense of humor? Visit Yahoo! TV's Comedy with an >> Edge to see what's on, when. >> http://tv.yahoo.com/collections/222 >> > > > > ---------------------------------------------------------------------- > --- This SF.net email is sponsored by DB2 Express Download DB2 Express > C - the FREE version of DB2 express and take control of your XML. No=20 > limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > > > > > > > ______________________________________________________________________ > ______________Ready > for the edge of your seat? > Check out tonight's top picks on Yahoo! TV. > http://tv.yahoo.com/ >=20 |
|
From: Jimmy Z. <cra...@co...> - 2007-07-03 19:23:35
|
If the processing takes place in the same process space, then if the goal is to make changes to XML payload, then would it be possible to put the "changes" in a seperate structure? there may not be a need to store the changes in XML itself you don't really have to put something in XML just to read it back out again, why not just accessing the info directly? ----- Original Message ----- From: "Tatu Saloranta" <cow...@ya...> To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" <vs...@am...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 8:19 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? > Yes, I am assuming this since the original question definitely sounded > like it was an in-process modification -- otherwise it wouldn't have made > sense. > > It is true of course that when travelling over the network, process > boundaries etc, some serialization is needed. > > -+ Tatu +- > > ----- Original Message ---- > From: Jimmy Zhang <cra...@co...> > To: Tatu Saloranta <cow...@ya...>; "Sun, Vanessa" > <vs...@am...>; vtd...@li... > Sent: Monday, July 2, 2007 10:34:25 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > Ok, I think the assumption here is that everything happens within > a single process... > but pipelining usually is more broadly defined as passing XML data > across process's boundry (even across the network, e.g. SOA components) > between mutiple programs... like unix's IPC, in that case, it is usually > not possible to pass a DOM tree around without re-serializing... > > ----- Original Message ----- > From: "Tatu Saloranta" <cow...@ya...> > To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" > <vs...@am...>; > <vtd...@li...> > Sent: Monday, July 02, 2007 9:45 AM > Subject: Re: [Vtd-xml-users] update-operation impact, if any? > > >> --- Jimmy Zhang <cra...@co...> wrote: >> >>> It is not much different from DOM, albeit VTD-XML's >>> more efficient... >>> when you send DOM downstream, still need to >>> serialize... >>> for VTD-XML, you just call XMLModifier's output()... >> >> Not necessarily, more often it's all within a single >> process, the tree model just gets passed. If so, no >> additional serialization or parsing is needed. >> >> I think it is fair to say that different models are >> more optimal for different use cases, and that heavy >> modifications are amongst hardest use cases for >> extractive parsers to implement efficiently (as >> opposed to read-only that is the most optimal). >> >> Regarding original problem -- it is of course possible >> to move from basic DOM to other Java tree >> alternatives. Also, most xml processing overhead might >> not come directly from DOM model itself: it is good to >> profile to see if it might have to do with other >> processing (xslt if it's being used, xpath, naive >> business logic that uses too much traversal). >> >> -+ Tatu +- >> >> >> >> >> ____________________________________________________________________________________ >> Sick sense of humor? Visit Yahoo! TV's >> Comedy with an Edge to see what's on, when. >> http://tv.yahoo.com/collections/222 >> > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Vtd-xml-users mailing list > Vtd...@li... > https://lists.sourceforge.net/lists/listinfo/vtd-xml-users > > > > > > > ____________________________________________________________________________________Ready > for the edge of your seat? > Check out tonight's top picks on Yahoo! TV. > http://tv.yahoo.com/ > |
|
From: Jimmy Z. <cra...@co...> - 2007-07-03 18:58:07
|
DOM in itself doesn't providing data synchronization, so I imagine you will need to do that if one thread is reading, the other thread is writing... ----- Original Message ----- From: "Sun, Vanessa" <vs...@am...> To: "Tatu Saloranta" <cow...@ya...>; "Jimmy Zhang" <cra...@co...>; <vtd...@li...> Sent: Tuesday, July 03, 2007 10:37 AM Subject: RE: [Vtd-xml-users] update-operation impact, if any? Yes, this is a in-memory process pipeline. No need to serialize until the dom reached the end of the pipeline. We used xpath as well, the performance degradation seems to be proportional to the size of the document, a linear degradation is a big scalability problem. Not to mention the dom size issue and the GC ... -------------------------- Cheers, Vanessa -----Original Message----- From: Tatu Saloranta [mailto:cow...@ya...] Sent: Tuesday, July 03, 2007 8:19 AM To: Jimmy Zhang; Sun, Vanessa; vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? Yes, I am assuming this since the original question definitely sounded like it was an in-process modification -- otherwise it wouldn't have made sense. It is true of course that when travelling over the network, process boundaries etc, some serialization is needed. -+ Tatu +- ----- Original Message ---- From: Jimmy Zhang <cra...@co...> To: Tatu Saloranta <cow...@ya...>; "Sun, Vanessa" <vs...@am...>; vtd...@li... Sent: Monday, July 2, 2007 10:34:25 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? Ok, I think the assumption here is that everything happens within a single process... but pipelining usually is more broadly defined as passing XML data across process's boundry (even across the network, e.g. SOA components) between mutiple programs... like unix's IPC, in that case, it is usually not possible to pass a DOM tree around without re-serializing... ----- Original Message ----- From: "Tatu Saloranta" <cow...@ya...> To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" <vs...@am...>; <vtd...@li...> Sent: Monday, July 02, 2007 9:45 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? > --- Jimmy Zhang <cra...@co...> wrote: > >> It is not much different from DOM, albeit VTD-XML's more efficient... >> when you send DOM downstream, still need to serialize... >> for VTD-XML, you just call XMLModifier's output()... > > Not necessarily, more often it's all within a single process, the tree > model just gets passed. If so, no additional serialization or parsing > is needed. > > I think it is fair to say that different models are more optimal for > different use cases, and that heavy modifications are amongst hardest > use cases for extractive parsers to implement efficiently (as opposed > to read-only that is the most optimal). > > Regarding original problem -- it is of course possible to move from > basic DOM to other Java tree alternatives. Also, most xml processing > overhead might not come directly from DOM model itself: it is good to > profile to see if it might have to do with other processing (xslt if > it's being used, xpath, naive business logic that uses too much > traversal). > > -+ Tatu +- > > > > > ______________________________________________________________________ > ______________ Sick sense of humor? Visit Yahoo! TV's Comedy with an > Edge to see what's on, when. > http://tv.yahoo.com/collections/222 > ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Vtd-xml-users mailing list Vtd...@li... https://lists.sourceforge.net/lists/listinfo/vtd-xml-users ________________________________________________________________________ ____________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ |
|
From: Sun, V. <vs...@am...> - 2007-07-03 17:37:52
|
Yes, this is a in-memory process pipeline. No need to serialize until the dom reached the end of the pipeline.=20 We used xpath as well, the performance degradation seems to be proportional to the size of the document, a linear degradation is a big scalability problem. Not to mention the dom size issue and the GC ... -------------------------- Cheers, Vanessa -----Original Message----- From: Tatu Saloranta [mailto:cow...@ya...]=20 Sent: Tuesday, July 03, 2007 8:19 AM To: Jimmy Zhang; Sun, Vanessa; vtd...@li... Subject: Re: [Vtd-xml-users] update-operation impact, if any? Yes, I am assuming this since the original question definitely sounded like it was an in-process modification -- otherwise it wouldn't have made sense. It is true of course that when travelling over the network, process boundaries etc, some serialization is needed. -+ Tatu +- ----- Original Message ---- From: Jimmy Zhang <cra...@co...> To: Tatu Saloranta <cow...@ya...>; "Sun, Vanessa" <vs...@am...>; vtd...@li... Sent: Monday, July 2, 2007 10:34:25 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? Ok, I think the assumption here is that everything happens within a single process... but pipelining usually is more broadly defined as passing XML data across process's boundry (even across the network, e.g. SOA components) between mutiple programs... like unix's IPC, in that case, it is usually not possible to pass a DOM tree around without re-serializing... ----- Original Message ----- From: "Tatu Saloranta" <cow...@ya...> To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" <vs...@am...>; <vtd...@li...> Sent: Monday, July 02, 2007 9:45 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? > --- Jimmy Zhang <cra...@co...> wrote: > >> It is not much different from DOM, albeit VTD-XML's more efficient... >> when you send DOM downstream, still need to serialize... >> for VTD-XML, you just call XMLModifier's output()... > > Not necessarily, more often it's all within a single process, the tree > model just gets passed. If so, no additional serialization or parsing=20 > is needed. > > I think it is fair to say that different models are more optimal for=20 > different use cases, and that heavy modifications are amongst hardest=20 > use cases for extractive parsers to implement efficiently (as opposed=20 > to read-only that is the most optimal). > > Regarding original problem -- it is of course possible to move from=20 > basic DOM to other Java tree alternatives. Also, most xml processing=20 > overhead might not come directly from DOM model itself: it is good to=20 > profile to see if it might have to do with other processing (xslt if=20 > it's being used, xpath, naive business logic that uses too much=20 > traversal). > > -+ Tatu +- > > > > > ______________________________________________________________________ > ______________ Sick sense of humor? Visit Yahoo! TV's Comedy with an=20 > Edge to see what's on, when. > http://tv.yahoo.com/collections/222 >=20 ------------------------------------------------------------------------ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Vtd-xml-users mailing list Vtd...@li... https://lists.sourceforge.net/lists/listinfo/vtd-xml-users =20 ________________________________________________________________________ ____________Ready for the edge of your seat?=20 Check out tonight's top picks on Yahoo! TV.=20 http://tv.yahoo.com/ |
|
From: Tatu S. <cow...@ya...> - 2007-07-03 15:19:26
|
Yes, I am assuming this since the original question definitely sounded like it was an in-process modification -- otherwise it wouldn't have made sense. It is true of course that when travelling over the network, process boundaries etc, some serialization is needed. -+ Tatu +- ----- Original Message ---- From: Jimmy Zhang <cra...@co...> To: Tatu Saloranta <cow...@ya...>; "Sun, Vanessa" <vs...@am...>; vtd...@li... Sent: Monday, July 2, 2007 10:34:25 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? Ok, I think the assumption here is that everything happens within a single process... but pipelining usually is more broadly defined as passing XML data across process's boundry (even across the network, e.g. SOA components) between mutiple programs... like unix's IPC, in that case, it is usually not possible to pass a DOM tree around without re-serializing... ----- Original Message ----- From: "Tatu Saloranta" <cow...@ya...> To: "Jimmy Zhang" <cra...@co...>; "Sun, Vanessa" <vs...@am...>; <vtd...@li...> Sent: Monday, July 02, 2007 9:45 AM Subject: Re: [Vtd-xml-users] update-operation impact, if any? > --- Jimmy Zhang <cra...@co...> wrote: > >> It is not much different from DOM, albeit VTD-XML's >> more efficient... >> when you send DOM downstream, still need to >> serialize... >> for VTD-XML, you just call XMLModifier's output()... > > Not necessarily, more often it's all within a single > process, the tree model just gets passed. If so, no > additional serialization or parsing is needed. > > I think it is fair to say that different models are > more optimal for different use cases, and that heavy > modifications are amongst hardest use cases for > extractive parsers to implement efficiently (as > opposed to read-only that is the most optimal). > > Regarding original problem -- it is of course possible > to move from basic DOM to other Java tree > alternatives. Also, most xml processing overhead might > not come directly from DOM model itself: it is good to > profile to see if it might have to do with other > processing (xslt if it's being used, xpath, naive > business logic that uses too much traversal). > > -+ Tatu +- > > > > > ____________________________________________________________________________________ > Sick sense of humor? Visit Yahoo! TV's > Comedy with an Edge to see what's on, when. > http://tv.yahoo.com/collections/222 > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Vtd-xml-users mailing list Vtd...@li... https://lists.sourceforge.net/lists/listinfo/vtd-xml-users ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ |
28 messages has been excluded from this view by a project administrator.
