> On 13 Jan 2015, at 11:20, Graham Cox <graham....@bigpond.com> wrote:
>
> Thanks - sorry I missed it in the first mail for some reason.
>
> An interesting thread. This remark from Quinn stood out for me:
>
> "If you stop issuing new requests, NSURL{Session,Connection} quickly recovers
> this memory to the point where, at the end of a cycle like this, the memory
> use (as shown by Allocations) is pretty much the same as when you started (a
> generational analysis shows just a few KiB of growth). So the problem here
> is not a leak, or even abandoned memory, but rather a delay in recovering
> memory."
>
> This could be what I'm seeing as well, since as a stream is downloaded, each
> chunk is pretty much requested as soon as the previous one completes, and is
> triggered by that completion (though I am rescheduling it on the main thread,
> which in turn adds it to the session's operation queue).
Yes I saw that in the code you posted way up there in the thread sometime and
that’s what made me think of that devforums thread which I have no idea why I
was reading in the first place. But indeed the recollection I had was that the
poster in that thread was also chaining new requests to the completion of old
ones and that appeared to be triggering the memory growth behaviour in his app.
>
> What's not clear is what is needed to cause the memory recovery to occur. I
> presume that invalidating the session will do that, but that isn't
> appropriate for in-between chunks.
I think ‘taking a break’ is probably what’s necessary to cause the memory
recovery to occur. Whether that means delaying 1 second between every request,
or doing a batch of 50 and then not issuing another request for 1/2 a minute I
have no idea, but it’s probably pretty simple to put in code which does N
requests and then waits T seconds before doing the next one then trying some
values of N and T to see if it does anything at all.
>
> I'll look into this angle and see if I can prove anything. If so, I'll file a
> radar and hope it comes back as dupe, fix imminent :) (though I won't be
> holding my breath)
>
well you might get one of your hopes there :)
_______________________________________________
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
