On Mar 15, 2010, at 1:11 PM, Andrew James wrote:
That being said, once containers get large, understanding the Big O
notation for operations can become important factors in choosing one
implementation over another. One of the things I do like about STL
( don't want to digress too far in this direction ) is that
documentation provides gaurantees about Big O notation.
Do this type of gaurantee exist anywhere in Cocoa's containers?
No. There isn't even any documentation about the underlying data
formats or algorithms used by the container classes; you just use the
nice shiny APIs. Very Apple-like :)
I missed the start of this thread, but I'll add (perhaps redundantly)
that NSArray, at least its mutable variety, at large sizes switches
from a flat vector implementation to one that's more of a two-level
tree. This is done to keep insertions and deletions fast. I think what
motivated this implementation is that mutable NSArrays are heavily
used in the Cocoa text system.
As always, you should be avoiding thinking about such details until
you've written your code, profiled it, and identified actual hot-spots
involving arrays. Also, you should be using NSArray's sort methods
rather than trying to make your own, since those methods have direct
access to the internal array guts and can work much faster than you
going through the API.
—Jens_______________________________________________
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
