tag:blogger.com,1999:blog-5568788882760066320.post648409894392905530..comments2018-08-27T15:40:06.058+02:00Comments on lichtblau's blog: Klacks parsingDavid Lichteblauhttp://www.blogger.com/profile/05088343424853670990noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-5568788882760066320.post-10920393223805117182009-11-23T01:37:01.967+01:002009-11-23T01:37:01.967+01:00you might also want to look at vtd-xml, the latest...you might also want to look at vtd-xml, the latest and most advanced XML processing API available today<br /><br /><a href="http://vtd-xml.sf.net" rel="nofollow">http://vtd-xml.sf.net</a>anon_anonhttps://www.blogger.com/profile/14424619310452413715noreply@blogger.comtag:blogger.com,1999:blog-5568788882760066320.post-27608985486819152952008-06-25T15:08:00.000+02:002008-06-25T15:08:00.000+02:00Thanks for the info!BTW, after re-reading my comme...Thanks for the info!<BR/><BR/>BTW, after re-reading my comment, the impression I left was that I didn't like CXML. On the contrary, I like it better than all the Common Lisp libraries I've found, especially for the DOM support and DOM speed.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5568788882760066320.post-10538673440217897592008-06-22T16:50:00.000+02:002008-06-22T16:50:00.000+02:00Hi Paolo,klacks is definitely unoptimized currentl...Hi Paolo,<BR/><BR/>klacks is definitely unoptimized currently. For me, its major feature was the pull-based approach, which is essential for some stream-based XML formats like XMPP. Obviously, I'd be glad to accept patches improving speed, but currently I am not working on klacks optimization issues myself.<BR/><BR/>As far the "lispy" API is concerned (use of multiple values is a part of that), this is not where I would start looking for speed issues. Perhaps it would be possible to add more API functions that go for raw speed, but the bulk of the problems are probably not in the API.<BR/><BR/>For one thing, klacks shares nearly all code with the SAX parser currently. It even sends SAX events for everything (not just the DTD) which then get discarded. So due to that implementation trick, klacks is automatically slower than SAX.<BR/><BR/>The creation of objects is an issue separate from the use of multiple values. What goes on here is that the values are currently consed into a list by the source. So there are actual "objects" in the current implementation, you just don't see them. This could contribute to speed issues.<BR/><BR/>But again, most of these issues should be fixable with a bit of refactoring. I just don't have the time for that right now.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5568788882760066320.post-59730338919930370652008-06-20T18:10:00.000+02:002008-06-20T18:10:00.000+02:00I've tested performance of CXML SAX and Klacks wit...I've tested performance of CXML SAX and Klacks with no processing whatsoever (i.e. parse with default-handler and a peek-next loop until nil), and Klacks is substantially slower that SAX. In fact, it's even slower that DOM.<BR/><BR/>I believe this is so because of the lispy way of doing it. I also believe this problem also happens with StAX with the event way, which creates objects for everything.<BR/><BR/>So, this enum vs object seems meaningful in terms of performance. Or I may be wrong and Klacks is not yet optimized. Which one is it?<BR/><BR/>PS: I've seen SAX code in a Klacks source file, apparently for some DTD processing. Is this relevant?Anonymousnoreply@blogger.com