xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <james.david...@eng.sun.com>
Subject Re: [spinnaker] Announce
Date Mon, 10 Jul 2000 21:00:34 GMT
on 7/10/00 8:37 AM, Arnaud Le Hors at lehors@us.ibm.com wrote:

>> After quite a bit of
>> discussion, the rest of the XML team at Sun, the people who are responsible
>> for the parser that will ship in the core of future JDKs, agree as well. It
>> is important to stress that we want to ship an Apache based parser in the
>> JDK for all the reasons that you'd expect.
> 
> It is crystal clear that this is all about Sun, not James as individual,
> despite his later claims. Just a fact.

Um, yes, I painted this badly. But of course the people that I talk about
this first with are the people that I work with. Duh. That doesn't make it a
Sun move. If you wasn't clear what I said earlier, the Sun team wasn't sure
about doing this.

But... See it as you will. I'm not going to put more effort into defending
myself on this issue. I'm going to go try and get something done.

> Did your code work slower on the Pentium II than on the Pentium I or
> x86? I doubt it. It's also my experience that in the long run your code
> works faster when you let the compiler do the optimizations. But it's
> beside the point here. What we are seeing with Hotspot is that it is
> slower than a regular VM (with a JIT). Profiling reveals that it fails
> to compile most of the code and runs most of it in interpreted mode. Not
> only that, but it performs better when profiling is on!! If this isn't a
> proof that something is really wrong in Hotspot I don't know what is!
> Besides, if anyone (and people from Sun in particular since I expect
> them to be the best experts in the matter) would help improving Xerces
> performance over Hotspot it would be great!!!

To improve Xerces performance on Hotspot necessitates pulling out almost all
the careful and deep optimizations that you've done. I don't think that
you'd be agreeable to that since you are still shipping a large number of
parsers to people that are on JDK 1.1 and it *would* pull down your
performance there. Heck, I wouldn't agree with changing the current Xerces
for that reason.

If you are going to take out the optimizations (a big job in Xerces because
you guys have done a good job in finding all the places that need to be
tweaked), then it's time to look at a rewrite.

> You're completely missing the point. My point is that James argument
> that the fact that most bits come from IBM Cupertino proves that Xerces
> is too complex is bogus. This has nothing to do with IBM vs Sun. Read
> what I write not what you want to read.

I wish people would read what I write as well instead of what they want to
see. :)

But, my point is that it's an extremely complex sourcebase. And so far most
of the people that have successfully approached it are people that are
working on it 40 hours a week. I meant no malice by the "IBM Cupertino"
remark. Just that it is where people are getting paid money to work.

> For one thing, I don't
> think this project can afford wasting resources. Andy Clark, Jeff
> Rodriguez, and Eric Ye are struggling to finish up the implementation of
> XML Schemas. I'm sure they wouldn't mind any help.

Bluntly, it's not a waste of resources if the people that are wanting to
start off working on Spinnaker aren't going to work on Xerces. Point blank,
if I'm not working on Spinnaker, then I'm going to be working on Crimson for
other deliverables. The Xerces codebase doesn't met my objectives. I'm not
going to try to work on it any further than the effort that I've put into it
to understand it to date. Therefore, you're not losing out on my time and
effort.

Should Apache lose out on this because I'm willing to put my time into
something new?

> It's just that I have more faith in evolution than revolution.

I have faith in both. Sometimes one is needed. Sometimes another is needed.
As a software engineer, you can't tell me that there haven't been projects
that you worked on where you wanted to try something new.

.duncan


Mime
View raw message