Re: Allocating too much memory kills my App rather than returning NULL
Re: Allocating too much memory kills my App rather than returning NULL
- Subject: Re: Allocating too much memory kills my App rather than returning NULL
- From: Jens Alfke <email@hidden>
- Date: Mon, 07 Nov 2011 15:59:32 -0800
On Nov 4, 2011, at 6:40 PM, Don Quixote de la Mancha wrote:
> I store the grid as an array-of-arrays rather than a two dimensional
> array. That is, I have an array of pointers which has the same number
> of elements as there are rows. Each row is array of unsigned longs,
> with the number of elements being the number of columns divided by
> thirty-two.
What’s the reason for that? I think it will hurt performance, both because it’s more expensive to look up the rows, and because locality of reference will suffer. Also, drawing will be slower because you can’t draw the entire board in one blit as you could if it were a pixmap.
(Actually, for best performance you should look into using a GPU shader function to update the automaton. That should really scream, and I’d be shocked if some enterprising demo-scene coder hasn’t implemented it already.)
> At this point in my application there is only one thread.
Yes, but the OS runs other threads for tasks like animations, network I/O, etc. and those are allocating memory too.
> Also I'm pretty sure the iOS memory allocator is multithreaded, and
> that Apple's code would be good about checking for runtime failures.
> If it does not, then that is a bug in the iOS.
The allocator is multithreaded; it’s your approach to backing out that’s not thread-safe. If you accidentally eat up all available memory, you can’t assume you have time to back out by freeing everything before anything else tries/fails to allocate memory. There are other threads that could be calling malloc at arbitrary times relative to your thread.
In general, higher-level code is not very graceful about handling out-of-memory situations. That’s because they’re rare nowadays [although less rare on iOS…] and because bulletproofing your code against them is excruciatingly difficult. There are so very many memory allocations, and once one fails you can’t do anything to handle the failure that might allocate more memory (such as creating an error object…) I’ve dealt with this in the Bad Old Days of the Classic OS, and it’s nearly impossible to get right.
—Jens
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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