Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] profiler

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: Wolfgang Hoschek <whoschek AT lbl.gov>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] profiler
  • Date: Tue, 23 Nov 2004 21:02:37 -0500

Wolfgang Hoschek wrote:
Allow me to speculate that the xom source snippet below might have to do with the just mentioned profiler and/or client VM problems, or similar reasons:


This comment goes back to when I was developing on Linux, not the Mac. If you could demonstrate conclusively that this was a problem, I'd consider revisiting it. However. these sorts of low-level optimizations really do run the risk of hurting more than they help. Even if they work today on one particular VM with one batch of test documents, that can turn completely around on another VM processing documents with different characteristics.

Algorithm-level optimizations like caching the namespace URIs and short-circuiting the scheme checking for http seem a lot more reliable and effective. I'm not sure how many more of these there are to be found though. Possibly we could cache element names as well, but that would need a much bigger cache and a lot more search time than namespace URIs, so it might well not help. Possibly I could cache namespace prefixes separately. Those tend to repeat, and not to be excessively numerous so there shouldn't be too much cache thrashing. That might help documents that use namespace prefixes. I'll put that on my TODO list.

Another reason I don't want to be too aggressive here is simply that this is not where most applications spend most of their time. Almost every real world application I've seen is limited by one or more of three things:

1. Input, including parsing.
2. Output, including serialization
3. Non-XML operations like encryption and decryption

NUX is a little unusual here because it does its own parsing and serialization; but I still suspect in practice a lot of time will get spent in raw I/O. There's a good reason most XML benchmarks precache documents in memory to0 avoid I/O costs. If they didn't, I/O would swamp everything they're trying to measure. Even if we succeeded in reducing in-memory operations to zero, I'm afraid it wouldn't have much effect on most applications. :-(

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim




Archive powered by MHonArc 2.6.24.

Top of Page