Thank you, Rob, Rich Scott, and Quincey for these answers.
I'm new to the programming world, so I think the first thing to do is
to figure out exactly what I want and then what I need. If I have to
optimise something later, I will do it.
Since it is about an array of a measurement points of a X-rays planar
dose (just doses at points on a plan) on witch the statistical
calculations are only made once in a while, I will first stick with
the objects and take benefit of all the Cocoa frameworks that make
things easier.
But you've enlarged my horizon on some other aspects that I didn't
know :) I will dig deeper there too.
Thanks again!
Stanislas.
On Dec 18, 2008, at 6:55 PM, Rob Rix wrote:
Do the simplest thing that could possibly work. In some cases, like
if you need to be calling -performSelector:withObject: with each of
these things, that might be the NSArray. In your case, it sounds to
me like it’s the C array of floats.
Just my two cents.
Rob
On Dec 18, 2008, at 7:00 PM, Rich Collyer wrote:
"bit stupid" - no, but..
The resulting assembly from:
NSArray testArray = [NSArray alloc] init];
// TODO: fill array with a bunch of NSNumbers (floats)
int i;
float bigNum;
for (i = 0; i < [testArray count]; ++i)
{
bigNum *= [testArray objectAtIndex:i];
}
Will be a bit slower than the assembly of:
float testArray[SIZEOFARRAY];
// TODO: fill array with a bunch of floats
int i;
float bigNum;
for (i = 0; i < SIZEOFARRAY; ++i)
{
bigNum *= testArray[i];
}
mainly because the c array and be stuffed into a processor register
and there are no object manipulations involved.
However, you never know when Apple will do something tricky with
Grand Central Dispatch that will void this argument.
+++++++++++++++++++++++
Rich Collyer - Senior Software Engineer
rcoll...@ironkey.com
IronKey - The World's Most Secure Flash Drive
2008 SC Magazine Readers Choice Award Winner
2008 FOSE Best of Show Winner
2007 GCN Labs Reviewers Choice Winner
+++++++++++++++++++++++
On Dec 18, 2008, at 7:02 PM, Scott Ribe wrote:
Depends...
How likely are you to need to resize arrays? How often do you need to
allocate & free them? Both of these are easier with NSArray & the
framework's reference-counting memory management. On the other hand,
for
simple arrays of floats, packaging everything up into NSNumbers or
NSValues
is also a bit of work.
For a size of 1000, I don't think it could matter. Move up to larger
problem
sizes, and yes the overhead can become noticeable. I tried ripping
out some
NSArray stuff and replaced it with std::vector<int> in code that
displays a
large (>30,000) item outline view, and that got a 5% overall
improvement--not huge, but still a significant amount of time to
spend in
pure overhead in a tiny portion of the logic. And this 5% was after
the
big-picture optimization of the algorithms involved, which had greatly
reduced the use of the arrays in question.
The usual guideline applies--try it the easiest way first; then
optimize if
you need to.
On Dec 18, 2008, at 8:01 PM, Quincey Morris wrote:
There's nothing inelegant about using a classic C array for this.
You can allocate the memory for the array with malloc, for a classic-
classic solution, or allocate the memory as a NSData object for a
classic-hybrid solution. If you only want to do calculations with
the numbers, this seems like the obvious approach.
There's also nothing wrong with using a NSArray of NSNumber objects.
You might consider this solution if you think there might be side
benefits, or if it is easier to code somehow. For example, if you
have a NSArray of NSNumber objects, it's very easy to add a
NSTableView to your interface that displays them.
It's unlikely that calculating mean, variance, etc on 1000 NSNumber
objects is going to be a performance issue, unless you're doing
these calculations over and over.
So, choose the approach that gives the clearest, most maintainable
code, then (if necessary) measure the performance to see whether you
need to optimize your approach.
FWIW.
_______________________________________________
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
