OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: recursion in XML parser

[ Lists Home | Date Index | Thread Index ]
  • From: Tyler Baker <tyler@infinet.com>
  • To: Didier PH Martin <martind@netfolder.com>
  • Date: Wed, 14 Apr 1999 14:22:32 -0400

Didier PH Martin wrote:

> Hi David,
>
> <Comment>
> Hmm -- they are somewhat slower than Expat, but that's because they're
> running tight code loops in a virtual machine.  Still, when I was
> testing AElfred on a 166MHZ Pentium NT box back in late 1997, it could
> parse about 1MB/second with a good VM and a JIT, and the other good
> XML parsers are comparable in speed.
>
> Granted, Expat (with memory-mapped I/O) is about 10 times as fast as
> the faster Java-based XML parser, but that's a very misleading figure:
> in fact, the actual parsing usually occupies only a small amount of
> the time required for XML processing -- most of the time is usually
> taken up by your code that actually does something with the XML.
>
> Let's assume, then, that XML parsing occupies 10% of your
> application's overhead.  Even if you could build a parser that is
> 1000% faster, you'd still gain only 9% in actual execution speed.
> </Comment>
>
> <reply>
> I think that nobody would argue that Java has a lot of virtues that
> certainly speed of not one of them. To take your numbers David, If that part
> of the application is 10 times faster than any Java parser and that the app
> itself is 10 times faster also. The overall throughput is therefore 10 times
> faster. Which, in certain circumstances is what's required. We would then
> have an apps with a 10 times faster throughput. The state of the art for
> Java may change in the future as soon as other players like HP, Novell and
> IBM bring to the table their own technology and that Java would finally have
> the same competitive environment as other languages have. This could be
> beneficial for the language evolution as more brains think on how to improve
> the performances.
> </reply>

I think another point to David's findings is that microprocessors are on average becoming much
faster and much cheaper every year.  The reasons for this are myriad, but the inevitable
consequence of this is that organizations and software companies will now buy more hardware to
run slower software that is easier to maintain and more portable than buy ultra-efficient
software that is targeted to a particular platform.  When a new processor costs as much as one
software engineer's consulting fee per hour, what kind of costs do you think an organization
is more willing to bear?

The unfortunate thing about computer science is that it is all based on math and all of the
algorithms for basic data structures that have been devised are probably the only ones that
will be around for a very long time unless someone comes out with some new mathematical
breakthrough.  So we are left enslaved to the engineers at chip companies who are left with
the responsibility of figuring out ways to squeeze out more silicon per dollar than their
competitors.

As they say, there are only so many ways to skin a cat (-:

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS