Re: iterative process building huge stack
Re: iterative process building huge stack
- Subject: Re: iterative process building huge stack
- From: James Maxwell <email@hidden>
- Date: Sun, 30 Jun 2013 14:31:32 -0700
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 <email@hidden> 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
> email@hidden
> http://www.warplife.com/ <--- Real Soon Now.
>
> On 6/30/13, James Maxwell <email@hidden> 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 (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
>
>
> --
> 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 (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