Re: Native Cocoa vs Java performance question
Re: Native Cocoa vs Java performance question
- Subject: Re: Native Cocoa vs Java performance question
- From: Bill Bumgarner <email@hidden>
- Date: Sun, 6 Apr 2003 11:22:03 -0400
Adrian,
I'll take the 'you are probably all' as to indicate that this
should be opened up to the list at large again.
On Sunday, Apr 6, 2003, at 04:27 US/Eastern, Adrian Milliner wrote:
Hmm I don't think my test is a bad one. If you profile an application
and see that a lot of your wallclock time is spent dealing with
hashing, then a faster hashing mechanism is a good thing to have.
Yup -- given the rest of the story, you are absolutely correct...
You say that UI performance and tracking UI events is perhaps more of
a problem... well, I don't have a UI. Didn't mention that up front,
sorry :)
Ahhh... in that case, going with pure Java may very well be the right
answer for your application!
If you don't need the dynamic features of Objective-C -- if you are
implementing something much more akin to a calculation engine -- then
the portability, static binding, memory management, and raw performance
of a well implemented Java/JVM based solution may very well be the
right answer.
I have written or supported the writing of trading systems in Python,
Java, and Objective-C. The language of choice is merely making the
choice to sacrifice one feature for another.
In the system implemented in Python, we had to do data distribution
across dozens of clients from a single source with that source doing a
bunch of data analysis. We chose Python because we could right an
order of magnitude fewer lines of code to get the task done than we
could have gotten away with in ObjC -- we sacrificed raw performance
for the ability to role out a much more flexible product in an
extremely tight time frame.
Similarly, I have worked on systems that use Java because the project
has needed absolute portability (which Java is very good at as long as
you avoid the UI layers) and excellent performance. Going that route
did sacrifice the flexibility that can be had with the dynamic binding
available in Obj-C (though, now, through the use of Java interfaces, it
is possible to regain a lot of those advantages -- just not in quite an
elegant of manner).
You are probably all going to say "use c++ then!"... well my rationale
for trying the Cocoa route is one of purism. I want to write something
in the "Mac way".
But that would be the "mac way" every bit as much as using ObjC. One
of the beautiful aspects of the OS X platform is that you can write
code in Java, ObjC, C++, Python/Ruby/Perl, straight C, or assembly and
they are all native languages.
If you are talking about writing a non-GUI application, you are not
going to be using Cocoa at all. You could chose to use Objective-C +
Foundation, but that isn't Cocoa! Cocoa is just the API contained in
the Cocoa framework (really, the AppKit framework)-- Foundation is a
separate beast entirely (as is the ObjC runtime).
Also -- Foundation code can be extremely portable. The GnuStep
implementation of the Foundation APIs are relatively in sync with
Apple's Foundaiton. The AppKit layers have diverged a bit more over
the years.
It looks like the most performant way is to use Cocoa only for UI (if
you have one), preferences, Mac-specifics and use C++ for the actual
app code.. or even Java.
Depends on the object design. Given any random problem, the choice to
use ObjC may result in a higher performance solution simply because it
requires many fewer lines of code to be [written and] executed to get
the task done. This is the nature of dynamically bound languages.
With that said, there are many problems for which Java and C++ is the
right answer in the pure performance context.
On the UI integration front, you could choose to use Cocoa/Java. I
currently am implementing a pretty good sized project in Cocoa/Java and
it works just fine.
My day job right now is improving the performance of a large bond
trading system, so I am perhaps a little more sensitive to performance
issues than most people. To me, having a slow basic infrastructure is
bad start :(
Too many times I have seen a developer choose one solution over another
because raw performance analysis of a really small feature of one of
the solutions outperformed the other. The issues are always much
larger than that.
Since ObjC is an issue, it sounds like you have the freedom to
effectively choose the language of implementation and architecture for
this round of development. It also sounds like you have a legacy
system that you will effectively be reimplementing?
If the performance on the existing system sucks, why is that? Is it
honestly because it is bumping up against the wall of performance of
the language and underlying system?
Maybe I'm pessimistic, but I would assume that that is probably not the
problem. That, more likely than not, the system was architected in a
fashion that has some inherent inefficiencies. This could be because
of a poor architecture -- but it is equally, if not more, likely that
the performance issues have resulted from the original architecture not
fitting the final solution. When creating a new solution or
implementing a new idea, it is impossible to design an architecture
that can account for all of the new details that will be discovered
during implementation. As new features are added, there will always
be a bit of duct taping the new uncomfortably onto the old...
So -- with all that said -- choose the language that you are the most
comfortable working in; the one in which you will be the most
productive and that will yield a working solution the fastest. Since
you are writing what appears to be mostly a pure engine with the
potential for a UI bit to control preferences and possibly display
state, the presence/absence of the Cocoa APIs at this time are largely
irrelevant to the decision.
As far as UI is concerned, go Cocoa -- especially if you haven't used
it before. From the sound of it, the UI can be decoupled from the
engine entirely. Use something like Web Services to isolate the two--
implementing an XML-RPC interface between the two is easy, implementing
a simple network protocol for controlling/monitoring the engine from
the app is even easier. That would also give you the flexibility of
moving the engine off to a calculation engine type box [Xserve cluster,
for example] while still being able to control it remotely from a GUI
desktop.
b.bum
(If you need some more formal help with this kind of thing, CodeFab has
a bit of relevant experience... :-)
_______________________________________________
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.