[Tclxml-users] Fw: [tdom] Re: tclDOM or TDOM dilemma on Windows

[yahalom e. <Yah...@xo...>]

Hello

my personal experince with both packages tdom and dom points towards =
tdom.
I used the tcl implementation of dom on a commercial web application.
it used to much memory  needed to much cpu and it was slowwww. getting =
the C implementation to works failed (well I am not an expert in =
compling etc.. when things gets too compicated I loose it).
I moved to tdom (took me some time) but since then I am happy. parsing =
is fast and efficient.
I do had problem upgrading to 0.7 .I work with mod_dtcl and apache and =
version 0.7 crashes apache so I work with 0.5. I reported on this =
problem but it was not solved so support is a bit of an issue.
regarding tdom being in kitten. It is there but I tried it and if failed =
for me on linux.error :
387324couldn't load file "/tmp/tclWNC0ZN": /tmp/tclWNC0ZN: undefined =
symbol: Tcl_GetChannel
 dom worked (tcl parsing).


Thanks

Yahalom Emet
Software Developer
Xor Technologies Ltd.

Tel: +972 (0)4-6619164
E-mail: yah...@xo...
Web: http://www.xortechnologies.com


  ----- Original Message -----=20
  From: ro...@po...=20
  To: td...@ya...=20
  Cc: tcl...@li...=20
  Sent: Wednesday, January 08, 2003 6:38 AM
  Subject: Re: [tdom] Re: tclDOM or TDOM dilemma on Windows


  On  8 Jan, Steve Ball wrote:
  > Fra...@ce... wrote:
  >> My problem is to chose between the tclDOM and the tDOM families of
  >> development for using it on Windows environment, without having to =
compile
  >> anything (sorry I do that as a hobby and I have no time to =
configure Linux
  >> nor even to play with a Visual C compiler - although it was my job =
several
  >> years ago ;-} ).
  >=20
  > I'm also working with Jean-Claude Wippler to include these
  > packages in kitten, so that one can write a StarKit that
  > makes use of XML & XSLT.

  kitten already includes versions of both tDOM and TclXML et
  al. Therefor you could in deed write a Starkit that makes use of XML &
  XSLT, no matter which of the packages you choose.

  > At the C level I believe TclXML, et al, is more advanced.
  > The TclXML family is fully TEA2 compliant, is Stubs enabled
  > and sports a layered architecture that allows extensions.

  Well, tDOM has a TEA2 build system (thanks to Zoran), is stubs enabled
  and has an architecture that allows extensions.

  > There's also the issue of support.  Many more developers use
  > libxml2 & libxslt, so it is better tested.

  So you're suggesting, that especially libxslt is more compliant and
  bug free than the tDOM XSLT engine, don't you? For sure you have also
  some hard facts for this, beside the fussy marketing speech? (Visual
  Basic is used by much more developers than tcl and therefor much more
  mature than tcl, or what is the argument?)

  Before the release of the current tDOM version 0.7.5 I run it against
  a suite of much more than 1500 xslt test files. The suite is compiled
  together from the (enormous) test suite of the xalan XSLT project
  (this alone are almost 1300 texts), the NIST XSLT test suite (more
  than 170 tests), the XSLTmark test suite, the libxslt tests, the
  various examples of Michael Kays "XSLT - Programmer Reference" book
  and a couple of other sources. I compared the tDOM results with the
  libxslt-1.0.22 results - the current version at that time, they are at
  libxslt-1.0.23 now - (and saxon, xalan-j and sablotron btw). I found,
  that libxslt had notable more failures than the tDOM xslt engine.

  Don't get that wrong. I confirm, that libxslt provides a good, almost
  compliant XSLT processor. (As, for example also the sablotron folks
  do.) Most of the libxslt failures, that I found, are related to not so
  common XSLT features or constructs and therefor libxslt will do most
  of the 'real world' XSLT right.=20

  But I state, that tDOM also provides a good, almost compliant
  XSLT processor - and probably a bit better, at least in some areas,
  than libxslt. Steve, please would you share the test results with us,
  that make you belive, it isn't this way?

  > I have no
  > comparative usage numbers for TclDOM/TclXSLT vs tDOM,
  > but you can check for yourself on the SourceForge project
  > page.

  The sourceforge tDOM project is only a placeholder, registered by
  Jochen more than 2 years ago, to protect the project name. Since the
  tDOM sourceforge project space was never used, it suggest, that there
  is no code and no users. Both is definitely not true ;-)

  > As far as performance goes, tDOM may be slightly better in
  > some circumstances but compared to the performance of Java tools
  > the difference is trivial.

  Hm. Steve, would you please name only a view cirumstances, for which
  tDOM isn't _at least_ slightly better than TclXML etc., as far as
  performance goes? ;-)

  What speed difference could be named 'trivial' depends of course on
  the viewpoint. But I, for once, would not confirm, that the speed
  difference between tDOM and TclXML compaired with the speed of Java
  tools is completely "trivial". If the java virtual machine has started
  and the classes are already loaded (the java virtual machine has
  'warmed up'), the rough numbers are as following: Given a modern, fast
  Java dom implementation, libxml is around two times faster, tDOM with
  the expat parser 3 times and tDOM with the simple parser 4 times.

  Another point is the memory footprint. A DOM tree needs a lot of
  memory. A libxml DOM tree needs typically more than double as much
  memory, as the tDOM DOM tree of the same document. For example, a just
  chosen random 17 MByte XML file needs clearly more than 100 MByte
  memory, as libxml DOM tree, and less then 50 MByte as tDOM DOM tree
  (numbers measured at linux). Sure, if you process only small XML files
  on a box with reasonable memory, that may not bother you much.

  Both the raw xml parsing/DOM building speed and the memory footprint
  are results with only moderate variations. It don't really matter,
  what half-way realistic XML document you use, tDOM is faster, while
  using lesser memory.

  XPath and XSLT are much more complicated. There is clearly a greater
  variation of the results. But the overall picture - my results, please
  provide your own - is pretty clear: tDOM xslt is notable faster than
  libxslt. I would say XSLT benchmarking is still in its first
  days. XSLTmark (http://www.datapower.com/xml_community/xsltmark.html)
  is probably the most known XSLT benchmark suite, at the moment. This
  are 40 different Stylesheets, which run 10 to 100 times against
  different source documents from a few bytes up to 2 MBytes. With the
  default test configuration, the XSLT transformation time sums up for
  libxslt to around 140 seconds and for tDOM to 75 seconds.

  My to some degree extensive XSLT benchmarking in deed shows, that
  libxslt is for example mostly much faster than sablotron - well,
  sablotron isn't that bad in compliance, as already said, but that the
  sablotron folks claim at there homepage: "Sablotron is a fast [XSLT
  processor]" is ludicrous and only possible, because nobody measures by
  itself --- do you (and especially Steve: do you)? I found tDOMs xslt
  engine often cleary faster than libxslt and only very seldom the other
  way around. And there's a hole group of stylesheet/(bigger) document
  combinations, for which libxslt is ridiculous slow.

  If you like more 'real live' numbers, Simon Hefi reports
  (http://groups.yahoo.com/group/tdom/message/286), that tDOM transforms
  the almost 1,7 MByte DocBook document Securing.xml more than double as
  fast as libxslt. At my a bit ancient box, libxslt (xsltproc) needs
  more than 50 seconds for that transformation, and tDOM only 25. By the
  way, a "warmed up" saxon also needs only a bit more than 60
  seconds. In such cases. I think it would be possible to say: the speed
  difference of libxslt to Java tools is "trivial", compared with the
  tDOM speed.

  > Finally, at least for TclXML & TclDOM there is a pure-Tcl
  > version for completely compilation-free deployment.

  It should not be suppressed, that especially the scripted TclDOM has
  its limits with respect to speed and its immens memory demand.


  Don't get me wrong. For private use and a small 'content management
  system' I guess both packages are probably very well suited; choose,
  whatever you like more. Steve, greased with the words, as it is, has
  in deed some tutorial material, which may help you on track. For sure
  an additional convenient plus for TclXML et al. is, that it is
  included in the ActiveTcl (for windows: probably not so far in the
  future) distributions. The long mail is mostly because Steve tends to
  get the numbers a bit wrong.

  rolf




        Yahoo! Groups Sponsor=20
              ADVERTISEMENT
            =20
      =20
      =20

  To unsubscribe from this group, send an email to:
  tdo...@eg...



  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.=20