• 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: The cost of using objects rather than plain C variables
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The cost of using objects rather than plain C variables


  • Subject: Re: The cost of using objects rather than plain C variables
  • From: email@hidden
  • Date: Sun, 07 Jul 2013 23:15:20 +0900


Sent from my iPhone

On 2013/07/07, at 16:33, Vincent Habchi <email@hidden> wrote:

> Hi!
> Thanks to all for your quick and kind answers.
>
>> You're comparing apples to oranges.
>
> That’s a nice way of putting it!
>
>> You were storing strings for each numeric value, now you're storing doubles.
>
> Actually just floats, in order to save space.
>
>> You could have tried NSNumber objects instead of strings, but better would be a custom object which holds the three doubles as ivars.  The former uses three objects per vertex, the latter using one object.
>
> I have tried NSNumber, but it didn’t save much space. I was unable to notice any significant gain.
>
>> Before you go much further, though, are you sure the memory was not just a high-water mark due to accumulation of autoreleased objects?  ARC isn't magic.  It doesn't relieve you of _all_ need to think about memory management and the proper deployment of autorelease pools is one of the things you still have to consider.
>
> I have put an @autorelease pool around the decoding code, but it didn’t change anything. You’re right, I think: the culprit is that the runloop never gets any opportunity to complete, so the autorelease pool cannot be drained. At a certain point, I receive a memory warning and shut all down. If I had run the decoding on a background thread, for example with [self performSelectorInBackground: withObject:] (which I ended up doing anyway, because I wanted to animate a UIProgressBar to keep the user informed of what was going on), would it have solved this issue?
>>
>> All of that said, though, it's perfectly reasonable to use C structs and arrays for large collections of simple data types.  I would not expect that Cocoa objects, used sensibly, would be 10x larger (a.k.a. 90% wasteful).
>
> I plainly agree my initial scheme could have been vastly improved, even sticking with Obj-C objects, but I was really struck by the figures I got. Is there any hope in the future to be able to store simple types like int or floats in NSArrays?
>
http://www.cocoaintheshell.com/2010/12/collections-integers-performances/

You can put pointers to plain old C types in a CFArray or CFMutableArray
Always consider Core Foundation collections when looking for performance
_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden


References: 
 >The cost of using objects rather than plain C variables (From: Vincent Habchi <email@hidden>)
 >Re: The cost of using objects rather than plain C variables (From: Ken Thomases <email@hidden>)
 >Re: The cost of using objects rather than plain C variables (From: Vincent Habchi <email@hidden>)

  • Prev by Date: Re: NSTextField / NSSecureTextField toggl
  • Next by Date: Re: The cost of using objects rather than plain C variables
  • Previous by thread: Re: The cost of using objects rather than plain C variables
  • Next by thread: Re: The cost of using objects rather than plain C variables
  • Index(es):
    • Date
    • Thread