• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Native Cocoa vs Java performance question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Native Cocoa vs Java performance question


  • Subject: Re: Native Cocoa vs Java performance question
  • From: Bill Bumgarner <email@hidden>
  • Date: Sat, 5 Apr 2003 20:55:56 -0500

On Saturday, Apr 5, 2003, at 20:23 US/Eastern, email@hidden wrote:
Why is Cocoa (native code) so much slower than Java? Or am I doing
something really bad Cocoa-wise?

Yes. You are doing something really bad. ;-)

Specifically; you are comparing raw performance of a single API used in a very tight loop. Basically, you are comparing the raw message passing and hashing performance of a dynamically bound, active, runtime [Objective-C] with a statically bound, passive, virtual machine [Java].

Java will always win in this case, but the test is largely irrelevant.

So much of what I need to do involves creating and maintaining large
hash tables, so on the face of it, I may be better off sticking with
Java... I hope not, because I do like Objective-C and Cocoa.

Are you really going to be sticking things in/out of hashes so often that the actual hashing performance is going to make that big of a difference in comparison to, say, drawing the user interface or tracking user events?

If hashing performance is really that big of a deal, use a C++ based collection API to handle the hashing bits...

It is much more likely that most of the CPU time used by your app will be spent dealing with the UI. Likewise, it is much more likely that most of your maintenance and development costs will be centered around building/extending/maintaining the UI.

In that context, the Cocoa APIs and tools will provide for much higher developer productivity and will yield an application that is likely more feature rich and less buggy than the Swing counterpart simply because you-- as the primary app developer-- have to do a boatload less work to realize the UI parts of the application.

--

In first working with the Cocoa APIs after having developing GUIs with other API, every developer out there will go down the path of thinking that ObjC message passing is a big bottleneck. I know I certainly did [of course-- I was working with NeXTSTEP 0.8 at the time and, as such, was optimizing List and HashTable, not NSArray/NSDictionary].

Invariably, the realization is made that-- in fact-- the real performance bottleneck is in getting the bits to the screen and tracking/responding to the user.

It isn't about how fast you can call the methods, it is about how many calls to the methods you can eliminate!

Example: Run Quartz Debug sometime and turn on "flash screen updates" and "flash identical updates". Anytime you see a yellow flash that includes more of an area of an application than actually needed to be redrawn, the CPU usage required to do that update was likely equivalent to several hundred of thousands, if not millions, of hash hits -- for table views, it often means many round trips to the data source, etc. (And if you see any red flashes, that's just bad).

b.bum
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Native Cocoa vs Java performance question
      • From: Jeff LaMarche <email@hidden>
  • Prev by Date: Native Cocoa vs Java performance question
  • Next by Date: PB "x" icon
  • Previous by thread: Native Cocoa vs Java performance question
  • Next by thread: Re: Native Cocoa vs Java performance question
  • Index(es):
    • Date
    • Thread