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: Mac OS X Java Performance

You guys really ought to let this thread die.

On Thursday, July 31, 2003, at 06:51 PM, Greg Guerin wrote:

Todd Blanchard <email@hidden> wrote:

In java if you have someObject.doSomething(argument) the method
doSomething *must* exist. The idea that it might not is simply
inconceivable.

On reflection, "inconceivable" may be too strong a word.

Or perhaps I should say "with reflection", since it is Java's reflective
capability that lets you call methods which may or may not exist on any
given instance.

Yes of course its possible - but it takes about ten lines of code to try to send a message this way. There's no way to handle is centrally within the receiver itself. If you are interested in an experiment using a preprocessor, I suggest you look at Bistro.

http://bistro.sourceforge.net/overview.htm

The other thing is Java's reflection facilities are one legged dog slow. A method lookup and invocation takes something like 50 times longer than a regular message send. If you aggressively cache method lookups (like I do in my keyValueCoding library) you can approach 5-10 times slower. If you generate bytecode to create single function objects that invoke the method in question on objects of the class in question directly (using BCEL for example) you can beat the built in Method's implementation by a lot and end up being only about half as fast as a direct call.

Most of this is beyond the abilities of the average developer and is only practical for special cases rather than as a Way of Life.

Trust me, I know pretty much all of the tricks Java can do. Its not that many.

I can even conceive of a language compiler that implemented this kind of
dynamism using Java reflection and wrote out class-files as the executable
form. Or it might instead perform source-level transformations where
necessary, which were then fed to an ordinary Java-language compiler. Sort
of a higher level of reflection (we could call it Prism). Who knows how
fast it would be, but it's still conceivable.

Sure compiler tricks - thats all we get. Java 1.5 is nothing but new compiler tricks. The core VM never improves. C++ was the mother of all compiler tricks. In the end it doesn't scale. The software remains rigid and fragile. Not amenable to change.

C++ was developed for doing operating systems for telephone switches. Java started out aiming at embedded systems. It sure would be nice to work in a language that was conceived from the beginning to enable flexible and rapidly evolvable systems.

As Gosling says himself:

One of the design principles behind Java is that I don't care much about how long it takes to slap together something that kinda works. The real measure is how long it takes to write something solid.

OK - you know how much the scenario matches enterprise development (what I and an awful lot of java developers do day after day)?

Not at all.

The real measure in my world is how fast can I get something that works. Extreme Programming is all about Smalltalk. It came from Smalltalk (along with test driven development - which largely obsoletes compile time type checking according to RC Martin).

The idea is to write some software - see what's wrong with it - refactor it and add more. How well does this match what Java's creator says its for? Not too well. In this environment - the tool that produces the most solid code is the most malleable environment that actively helps you find and fix bugs. Rigidity is the enemy.


Another capability DNU allows is the ability to be a proxy for some
chunk of data in a database. Its essentially a query waiting to be
triggered. On first invocation of DNU, the object executes the query
and does a become: queryResults forward: aMessageContext which replaces
itself with the results of the query and reinvokes the original
message. Thus you get object faulting.

You can design Java classes to do this. It's not that difficult, and there
are different approaches with different tradeoffs, though it doesn't use
DNU. It could use reflection, though, if that was the approach that best
fit your tradeoffs.

Its not a question of can you do it once. Can you do it all the time? I can do this in C too. Its a lot of work though. First I need to write an object model, then dispatching....its not practical.

You have to have a different one for every class that you might fault from the db. Like the network proxy. I laugh at the hoops CORBA and RMI developers jump through to create their dozens of proxies. What a waste. Incidentally, this violates Blanchard's law of software development that states that any environment that requires code generation is insufficient to accomplish the task at hand. IOW, code generation never scales.
_______________________________________________
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.
References: 
 >Re: Mac OS X Java Performance (From: Greg Guerin <email@hidden>)



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.