[speirsfr]

I just moved a Java App I had developed on LinuxPPC to McOS X Public Beta, and I was pretty shocked at just how poor the performance was on PB by comparison to Linux.

Can anyone verify that the Java in PB is full o' debug code or something? I seriously hope that the performance of Java on OSX is at least as good as Linux.

Considering the blackdown JVM has no JIT of any type, I would have expected OSXPB's to be at least comparable....

Or do I have to do something special to make the Hotspot VM operate?

Cheers,
Fraser

[Angus_D]

Well that's.. odd. OS X's Java VM is meant to be very fast. You could try moving from swing to Cocoa, if you could be bothered. That might increase speed significantly.

[speirsfr]

I don't think that it's Swing that's causing performance issues, unless Apple's is a different implementation from Blackdown's. Swing being pure java, I would expect that the Aquaified Swing is just a new set of look and feel managers for the existing Swing set.

It's more things like startup time, and interactive responsiveness that are substantially worse in Public Beta.

Let's hope all is relealed in 4 days.

[sadie]

Last time I looked at Swing, it was slower than treacle in liquid helium. Java is a nice language in places, but a few bits of it - bulk Image handling, particularly - are just designed badly.

Try building the same program in Cocoa and in Swing. You'll see a big difference.

[speirsfr]

Sadie, I take your point, but what I was more perturbed about was that a program that ran acceptably well on the Blackdown/Linux JDK with no JIT was a complete dog on OSX's Java VM which has Hotspot.

OK, it might run slower than a cocoa version, but it should run at least *similarly slowly* on both platforms, right?

I sure hope so.
Fraser

[sadie]

True. Like everything else, though, you'll just have to wait a few days and see the real thing.

[davecom]

I think the problem is not that the VM is slow, but that the Aqua implementation of Swing is slow.

------------------
Think Different.

[sadie]

I thought Swing wasn't implemented, but ran directly on top of the Java code - so the base system has no input into running it, unlike the AWT that uses native widgets and looks dreadful.

I thought that was the entire point of Swing? To escape from the platform running the program?

[eyadams]

No, there's implementation to Swing. Swing supports configurable look and feel. Each look and feel is implemented in a suite of classes that actually draw the widgets and handle user input. There are currently 4 or 5 popular look and feel implementations: Windows, Mac OS (Classic), Aqua, Motif, and Metal (the Java default).

The neat part about Swing (from the perspective of a Swing developer) is that no extra work is necessary to create an app that looks like a Macintosh app on the MacOS, a Windows app when running on Windows, a Motif application when running under Solaris, etc. In the standard Swing libraries there are methods that will provide the correct look and feel for the current platform - all the developer needs to do is call the API.

In practice, all this actually works suprisingly well. Simple, well coded Swing applications will actually look basically correctly on a variety of platforms without modification. More complex applications do ultimately require some platform-specific event handlers (pop-up menus are specifically mentioned in the FAQ).

As to Swing apps being slow on PB compared to Blackdown on Linux, there really are too many variables to accurately place the blame. The Aqua look and feel may be slow; this could be tested by using the same look and feel on both platforms (Metal should work on all platforms). There may be some unoptimized bit of code in the application that is tripping up the PB JVM but doesn't cause problems under Blackdown; it would be worth testing the app on another JVM (Sun's JDK under Windows or Solaris, for example).

Erik

[speirsfr]

Hi,

A couple of points:

1. The app was using the Metal L&F, not Aqua, so it's not an issue with the Aqua L&F managers (which I know use Appearance Manager to render so they may be fast if that's optimised, or slow as it involves JNI calls - I've no real experience with JNI, other than to know it's a fair bit of overhead).

2. Potentially, Apple reimplemented the Metal L&F as well. It did look a little different to the Linux side (which looked like every other Metal app).

3. Erik's definitely right to say that there's many variables - I'm doing nothing more about this until next week and I see the production VM. THEN I'll complain, or cheer, depending.

Saturday will be good regardless of performance issues: Java2 on Mac - I thought I'd never, ever, see the day. As a developer, the unix base of OSX is just so the right decision. Think of it - when apple bought Next, linux was just a dream. Now Unix has essentially won the day and Apple is right there in the heart of it.

Imagine where we'd be if we had taken Be instead. Doesn't bear thinking about.

Ta-ta.
Fraz

[JavaMac]

" There may be some unoptimized bit of code in the application that is tripping up the PB JVM"

In PB, there was hardly any *optimized* code. But that was a long time ago

"Appearance Manager to render so they may be fast if that's optimised, or slow as it involves JNI calls"

It's not JNI, it's Apple's native JDirect (not J/Direct!), and the overhead for calling it is no worse than for other graphics calls - which, after all, are also native. There is a slight edge in that it takes 1 ApprMgr call to draw an Aqua button, while there may be a dozen graphics calls to draw a Metal one

"Potentially, Apple reimplemented the Metal L&F as well. It did look a little different to the Linux side"

Nah, you're just seeing glitches in the PB graphics. It's the same Metal as everywhere else.

[SmileyDude]

Actually, under the final, Java seems slow to me. But it may be just me... I just did a quick little hello world program, and ran it from the command line using the time command... this is what I got:

Code:
[imac:~] dennis% time java Test
Hello World!
0.420u 0.210s 0:00.66 95.4%     0+0k 0+5io 0pf+0w

While not insanely long, it did feel like a long time... maybe it's just me nitpicking...

------------------
dennis

[JavaMac]

Actually, under the final, Java seems slow to me. But it may be just me... I just did a quick little hello world program, and ran it from the command line using the time command...

Well, startup time is still not very good, but once it's running it should be much better.

[aetius]

For a comparaison of Java in Mac OS 9 and Mac OS X, see the maths applications "Surface" and "Triangulator" at
http://deshayes.freeservers.com/MacAetius/

5 times faster in OS 9 !!!