Lists Home |
Date Index |
- From: Kay Michael <Michael.Kay@icl.com>
- To: firstname.lastname@example.org
- Date: Thu, 15 Apr 1999 19:06:37 +0100
> My reasoning for not using recursion was performance
> (function call/stack framing
> considerations) and that it made the code easier to understand.
Did not-using-recursion make it faster? I'd be surprised. The superstition
recursion is slow dates back to COBOL and IBM 360 days, i.e. to machine
with very inefficient memory architectures and subroutine calls. I don't
know much about the Java VM, but I doubt it shares those characteristics.
"Easier to understand" is obviously in the eye of the beholder, but in my
recursive algorithms are usually far easier to understand than their
> It would be interesting to do some benchmarks on various
> parsers out there to measure performance. The Java parsers I've tested
> are _dog_ slow compared to expat, etc.
How slow is a dog (greyhounds are quite fast)? What kind of factor are you
talking about? A lot depends on your Java VM implementation. My experience
is that most of the mill is used in my application, not in the parser.
> For server-side I don't think that matters, since in the corporate scene
> tend to just add more servers/infrastructure and not worry about
Not true when you're serving a million pages a day! Except that in that
scenario we cache the rendered pages so we don't keep re-rendering the same
thing. But a factor of 2 in performance is definitely worth investing in.
> Client-side XML is a completely different kettle o' fish tho'
> since you can't just keep popping in processors every time your machine at
> home/work bogs down.
On the contrary: you've got a rather strange client configuration if it
takes longer to render a page on your machine than to download it.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)