Re: Create NSStrings from a mapped NSData object - safe?
Re: Create NSStrings from a mapped NSData object - safe?
- Subject: Re: Create NSStrings from a mapped NSData object - safe?
- From: Michael Vannorsdel <email@hidden>
- Date: Wed, 14 May 2008 00:28:07 -0600
Obviously this is less efficient than mapping which is why mapping is
still around. But it's kinda the only other option when mapping and
FS operations won't protect your mapped file. My point was that the
program and system will still run under heavy memory consumption,
albeit slowly. Just another case of shortcuts, reliability, vs
performance.
Indeed making string references can be tricky and requires attention
to detail. But it can help make up for the heavy memory consumption
of the in-memory data, which was the intent of my suggestion (bulk up
here, trim some there). If you know what you're doing this can
perform well, reliably, and be a fair trade off between performance
and predictability.
Until file protection locks are guaranteed, I would expect the
workaround to be less efficient and less elegant.
On May 13, 2008, at 11:32 PM, Jens Alfke wrote:
Yes, but it's less efficient than a mapped file, which doesn't have
to be swapped out at all.
The OS may have virtual memory, but swapping when the system is
under memory pressure is the chief performance problem in OS X; when
I worked at Apple, the performance people drilled it into us that
the most important optimization is saving memory. (For example,
that's why Release builds use -Os by default instead of -O2.)
This is tricky and dangerous. It's very difficult to predict object
lifespans in a ref-counted or GC'd environment, and if any of those
little strings are still being retained by something when you free
the big string, they all turn into land mines that will crash the
app the next time they're referenced.
It's possible to make this work, but I would only try it as a last-
ditch optimization if the sheer volume of copied strings was choking
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