Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Newbie question

James Mooney <email@hidden> wrote:

>One was written is Java and one is straight C (carbon api)
>
>Each did the same thing....takes an image, calls quicktime to decode the
>image data, recompress the image data into a newly resized jpg.
>
>Each was tested and the C app took about a half a second and the Java
>one took about 10 seconds. Mind you I did not implement QT in the Java
>one. I fed the app a jpg and just asked it to resize the image and
>store it again.
>
>On top one would think the Java app had a lot less work to do. But do
>to what I assume was the sluggish running of Java Runtime. I would
>expect this.

Why would one think the Java app had less work to do? That's not a
rhetorical question. I really want to understand the reasoning or
rationale behind why one would think that.

The startup of a Java app is slower than that of a C app. Java loads
classes on-demand. That means there has to be a demand for the class from
the running program. After classes are loaded, Java performance behavior
changes.

Java also compiles classes to native code as it determines how frequently
something is being called. That in turn affects one-off performance vs.
longer-running performance.

There's also the quality of code generated by the JITC, which varies by
platform, JVM, release version, and command-line options.

All of which contributes to difficulty in answering the question for the
general case.

And since pure performance is rarely the be-all and end-all (correctness
usually counts for something, unless you like buffer overruns as a way of
life), there is no one way to answer the question.


>My original question is directed to how Java is implemented in Cocoa.
>What is the end product, a compiled app, or a collection of byte code
>and library files that will need to be passed through a Java engine to
>run (hence a performance hit).

A Cocoa-Java app is a combination of native code (ObjC libraries providing
Cocoa functionality) and Java byte-codes. Some of the byte-codes will be
translated to native code (as needed) by the JITC, but you can't predict
when or where.


>I realize Sun would probably hate Apple doing that but it would seem
>like a great tool if Java apps ran native code upon a recompile....ie
>set target to byte code or machine code........

If it were easy, then I suspect there would be any number of products
available that do this. The fact that this area isn't a highly competitive
arena leads me to think that it's either not easy, not profitable, or some
other "not" that's keeping possible entrants away like stink on a dead
skunk.

In my experience, it's easy to think of great tools, but much harder to
actually make them.

-- GG
_______________________________________________
java-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/java-dev
Be sure to read the FAQ http://developer.apple.com/java/faq/ before posting
Do not post admin requests to the list. They will be ignored.


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.