... [earlier discussion] ...
NSIndexSet can use less than 1-bit per bit :)
(It compresses contiguous ranges)
In some cases, especially where 1s are relatively sparse, as with
selections. It can also take a whole lot more than 1 bit per bit,
since a
range is a pair of 32-bit ints.
... [future discussion] ...
The difficulty with NSIndexSet as a solution is that it doesn't
address the OP's question, which was how to control the performance
and memory characteristics of an array of BOOL data items.
The original scenario was a NSMutableArray of NS(Mutable?)String
objects each made up of a few hundred "0" or "1" characters. Trading
this in for a NSMutableArray of NS(Mutable?)IndexSet objects *might*
use less memory (or might not), but it might also be slower (because
of checking for coalescing of index ranges).
The key point is that most of the implementation details of NSIndexSet
are not known (and are not necessarily fixed for all time), so
performance/memory characteristics are essentially unknown. What's the
use of guessing?
Plus, the OP never stated what kinds of changes need to get made to
the BOOL items. For all we know, the whole data structure is
immutable. Or random BOOLs change thousands of times per second. The
optimal solution depends on knowing which.
To pin down the performance/memory characteristics, you must pin down
the implementation. That's why NSData in place of NSString seems to me
to be an excellent solution. You know how much memory is going to be
used (fractionally more than one byte per BOOL, on average, counting
NSData's overheads) and you know the performance cost (at worst a
method dispatch -- fractionally more than 1 function call, on average
-- and a C pointer plus offset per BOOL access, if you code it as
'data.bytes [index]'). These both seem very cheap, even if the target
environment is (say) an iPhone.
Of course, this doesn't address the NSMutableArray part of the
equation. We don't have enough information to know whether its
performance/memory characteristics need to be taken into account.
_______________________________________________
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 [EMAIL PROTECTED]
