Slashdot Mirror

In addition to being naive, I agree that there seems to be a little bit of MSFT adulation to blame from what I've read by Miquel. It seems he is entirely unaware of other competitive solutions such as, most obviously, Java.

MSFT uses it's monopoly to brilliant advantage against various adversaries. Had not Linus written Linux, I believe MSFT would own the server market in addition to desktop, having wiped out each overpriced, proprietary Unix one-by-one. Why those folks don't spend their valuable time working against MSFT instead of in their favor is beyond me.

It's sort of like Ralph Nader running for office and wondering why Republicans are supporting him. Suckers! They know the more successful Nader is the more votes taken away from the Dems!

Finally, here's what Sosnoski thinks, he's a rather sharp programmer living "in the Shadow of Redmond" so I think he knows what he's talking about, and he too points out that, while the Mono team is nowhere close to anything competitive to .NET, *even* if they do eventually get close, they will be talking to the lawyers.

My thoughts are, from past history, they won't even need to bother with lawyers. MSFT will just use it's old tricks they used against Borland and all the others, i.e. poorly documented or unpublished APIs, secret hooks, etc.

So many errors, so little time...

"a lot of problems that *would* require multiple machines can run on one machine simply by using C++ instead of Java"

According to benchmarks, even old versions of Java are within a factor of 2 in performance with C++. See Java Performance Comparison with C/C++.

"Sun is big about "scalability" aspects of it. The problem is that this only applies to problems that can't work on one computer, but *can* work on one computer times some constant that's relatively small from a computer science standpoint."

Why? A well written distributed application can scale to thousands of CPU's. So if you have a big problem to solve (weather modeling, Computational Fluid Dynamics, high volume transaction processing, molecular modeling, rendering movies, etc.), you can either solve it by waiting 15 years for CPU's to get 1,024 times faster, or by clustering 1,024 CPU's. So I agree with your point at as CPU's get faster, more and more problems can be solved on a single CPU, but I think that you're underestimating the number of problems that require lots of computational power to solve.

You don't think that eBay, or a bank, or an airline runs on 1 CPU, do you?

"The only benefits I see to IBM's approach is that companies can theoretically replace their local Windows boxes with thin clients and fire their local IT staff"

This isn't about the kinds of applications that you run on desktops! This is about being able to build virtual mainframes out of commodity "desktop" components.

As you suggested, I looked at the link. According to this graph the current crop of parsers can handle 2.9megs in about a second also. so the data would suggest the current crop of parsers are comparable to the results you stated. Since you seem to know much more about parsers than i do. Just as a theoritical excersize, would it be possible for someone to improve the performance another 100x?

I'm not trolling, I'm not exaggerating, and although I'm pretty good at making things run extremely fast, last time I looked I was only a mortal. It's true I fixed someone's bug recently and he did say I was a god, but I'm pretty sure that was just hyperbole. :-)

I mentioned "several years ago", "SAX/DOM", and IBM -- we were using the SAX/DOM package originally written by IBM (this was at go.com, if that helps), and it appeared to be practically an industry standard at that time, at least from what multiple people told me.

Yet it was buggy and slow -- which annoyed me at the time, and here people are claiming that whatever XML parsers they are using (most of the comments didn't mention), they're slow today too...that's what I was responding to.

Nowhere did I claim that I have one that is 100 fold faster than whatever is fastest today; I haven't followed the different XML parsers as they've been introduced. I don't even know what was the fastest available when I did this 5 years ago; after some unsuccessful searching I gave up and wrote a new one, because it's trivial (I'm a compiler guy, among other things).

The point I'm making is simple: either XML parsers are very fast...which I know is possible, because I created one...and people's complaints are unwarranted, or else they are using XML parsers that are much slower than they should be, and they should switch.

So if the XMLbench URL you provided leads people to much faster parsers, great. If they don't need to switch, then they don't need to complain, either.

Again, the point is that XML is not inherently slow. That point stands.

This is also just common sense. Look at the syntax. It's practically trivial. Related technologies like Xpath, XSLT, etc etc may have their own issues, but that's not the same as saying "XML is slow". Again, it's not.

As I recall I timed it at 3 megabytes of XML parsed per second on a Sparc desktop workstation of whatever model was popular 5 years ago...I forget. It could have been made even faster; I'm not claiming that what I did was as fast as possible. It was enough for it to improve on the IBM DOM/SAX parser.

P.S. Speeding things up 100-fold (when they're dreadfully slow to start with) is not uncommon for programmers who specialize in such things -- usually by changing the underlying algorithm e.g. from quadratic to linear, sometimes by avoiding virtual memory thrashing, sometimes just by vastly simplifying crufty spaghetti code. Other times it helps to understand cpu architecture, assembly language, compilers, operating systems...many purely application-level programmers don't, and hence don't see where the code they're writing has inefficiencies.

On the other hand, sometimes it's impossible to speed things up...if they were written by a guru to start with, then there's nothing left to improve.

P.P.S. The post I'm responding to suggested looking at XMLbench at xmlbench . A glance at the first page makes it look like a reasonable starting place.

that is a pretty bold claim. it's either a lame troll, or you're god. I've worked with several parsers and know the code of a couple different java implementations. the only way I can a custom parser beating SAX or Microsoft's XMLTextReader is one using binary encoding, or specialized for flat models. There are numerous excellent xml parsers out there. this article by Dennis M. Sosnoski does a pretty good job of comparing parsers. there are also numerous research papars comparing C/C++ parsers to java. None of them showed a 100x difference. If you not full of hot air, prove it!

I'd have to agree with people's assertion that performance intensive apps should use a custom protocol and preferably binary based or some kind of delayed stream parser that only accesses the XML node when the app calls for it. I believe Sun has an API in the works for XML stream parsing JSR 317. It's too bad the jsr is still in public review phase. I've written custom parser in the past using SAX and it can definitely improve performance if you convert it to an object model. The question is trade off between being generalized and performance.

In the case of a webservice that uses schema, it's going to be hard to get around the performance issue. An obvious solution in situations where XML is required is to send as little as possible and only get the nodes you need. In that respect XPP2 and XmlTextReader help, until you need the entire document and you use the whole document.

• Spades

• Sosnoski

• Jeanpaul