Hi Michael, Thanks so much for this info -- it's exactly the kind of help I need. I code with an almost criminal neglect for the hardware, so I'll study your message carefully (and follow up with much Googling, probably). And yes, because of the nature of the task, there's loads of recursion. So in all likelihood I'm blowing the stack to smithereens! cheers, J. On 2013-06-30, at 1:24 PM, Michael Crawford <mdcrawford@gmail.com> wrote:
Are you using any recursive algorithms?
You might be but not know it. For example the C standard library qsort() is recursive. It's worst case runtime is O( n^2 ). In the average case its stack size is O( log n ). I'm not dead certain but I think the worst case stack size is O( n^2 ) as well.
Look through all your code for any methods that have many local variables, any locals that are large, or very long methods. The compiler puts invisible temporaries on the stack. If you have a particularly long method, it will put more of them. The best thing to do is to break long methods down into several smaller ones, but it's quicker and easier to subdivide methods by enclosing portions of them in curly braces, thereby making basic blocks.
If you set a variable early in a method, but then don't use it until much later in the method, with something unrelated to that variable found in-between, that variable is likely to be saved to the stack.
Your code will run a lot faster if the compiler can store all your locals in registers, without any use of the stack at all. The ARM on iOS devices have 16 general-purpose registers, however one is used for the stack pointer and the other for the frame pointer. x86_64 has more registers than 32-bit i386 but still not as many as ARM.
It's a lot faster to allocate a local variable on the stack, but if that variable is in a recursive method, there will be multiple instances of it on the stack when you're down in the recursion. If you allocate it instead, there will only be the pointer on the stack.
Hope That Helps.
Mike Crawford mdcrawford@gmail.com http://www.warplife.com/ <--- Real Soon Now.
On 6/30/13, James Maxwell <jbmaxwell@rubato-music.com> wrote:
I have a process that's generating a bunch of MIDI files. The process itself runs okay, but if I request a large number of files and pause execution at some point part way through, I notice that there are literally thousands of frames on the stack. In some cases, it will crash before it finishes; presumably because it runs out of stack space. I am using ARC (for the first time), so I'm wondering if it has something to do with methods retaining arguments and/or data they're using??? Or perhaps it has something to do with writing the files, which happens within the loop? For the time being, this all happens on the main thread (not ideal, but also not a problem for me, at this stage) -- could that have something to do with it?
It's really not practical to post code, since there's a lot of it, and it would be hard to make it clear how everything goes together, but if anybody has any top-of-the-head thoughts about where to start looking, I'd appreciate it.
J. _______________________________________________
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: https://lists.apple.com/mailman/options/cocoa-dev/mdcrawford%40gmail.com
This email sent to mdcrawford@gmail.com
-- Michael David Crawford mdcrawford at gmail dot com
Custom Software Development for the iPhone and Mac OS X http://www.dulcineatech.com/custom-software-development/
_______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com