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: Mon, 01 Jul 2013 12:57:09 -0700
Okay, it turns out my problem was the result of an indirect recursion. I had three methods that formed a loop, but it didn't really need to be recursive! (doh!)
Just a stupid mistake… my actual (i.e., deliberate) recursive methods were totally fine.
Anyway, I pulled the three methods all into a single while loop and it seems good now.
Thanks,
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