NSURLConnection Without NSHTTPCookieStorage
-
I'm using NSURLConnection to fetch a URL over HTTP. When it does
that, I see (in ObjectAlloc) that it instantiates the shared
NSHTTPCookieStorage, which uses about 500K of RAM on my machine. Is
there a way to prevent it from doing this, since I know I won't be
needing the cookies? I've tried calling:
[request setHTTPShouldHandleCookies:NO]
on the URL request, but that doesn't help.
--Michael -
Without trying to be dismissive of the question, is there any reason
why this 500K is a problem for your app?
FWIW, it's entirely possible that very little of that space actually
consumes any real RAM; calloc'ing a 500K block typically shouldn't
force any existing pages out of RAM until someone actually accesses
the space. By way of example, if you calloc a 1GB block of RAM on a
128MB machine, it doesn't immediately write out 1GB of data to
virtual memory—it's only when you start touching the allocated pages
that you see VM kick in.
So in other words, if there's no cookies being sent, and this memory
isn't getting touched, it may not even be an issue.
(This is a simplification of the issue, to be fair—obviously no
allocated object can be entirely free. Very cheap, perhaps, but
nothing is free.)
On Aug 9, 2006, at 3:02 PM, Michael Tsai wrote:
> I'm using NSURLConnection to fetch a URL over HTTP. When it does
> that, I see (in ObjectAlloc) that it instantiates the shared
> NSHTTPCookieStorage, which uses about 500K of RAM on my machine. Is
> there a way to prevent it from doing this, since I know I won't be
> needing the cookies? I've tried calling:
>
> [request setHTTPShouldHandleCookies:NO]
>
> on the URL request, but that doesn't help.
>
> --Michael
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/jstiles%
> 40blizzard.com
>
> This email sent to <jstiles...>
-
On Aug 9, 2006, at 6:12 PM, John Stiles wrote:
> Without trying to be dismissive of the question, is there any
> reason why this 500K is a problem for your app?
Well, this code will run in some small apps--essentially helpers that
will be open all the time. It seems like a shame to waste that RAM.
Also, it wouldn't surprise me if other people have a lot more cookies
than I do, so that more than 500K is used per app.
> FWIW, it's entirely possible that very little of that space
> actually consumes any real RAM; calloc'ing a 500K block typically
> shouldn't force any existing pages out of RAM until someone
> actually accesses the space.
Actually, it's not allocating a big block, but rather 7,000
NSHTTPCookie objects and 7,000 NSHTTPCookieInternal ones. So I think
it's using real RAM.
I'm embarrassed to say that when I ran ObjectAlloc again, no memory
was used for cookies. I guess turning them off *did* work, and
somehow that change (which was in a framework) didn't get recompiled
into the app before I did my test (unless there's some other factor
I'm not aware of). So perhaps the lesson here is that it's well worth
using -setHTTPShouldHandleCookies:.
--Michael -
On Aug 9, 2006, at 5:59 PM, Michael Tsai wrote:
> On Aug 9, 2006, at 6:12 PM, John Stiles wrote:
>
>> Without trying to be dismissive of the question, is there any
>> reason why this 500K is a problem for your app?
>
> Well, this code will run in some small apps--essentially helpers
> that will be open all the time. It seems like a shame to waste that
> RAM. Also, it wouldn't surprise me if other people have a lot more
> cookies than I do, so that more than 500K is used per app.
>
>> FWIW, it's entirely possible that very little of that space
>> actually consumes any real RAM; calloc'ing a 500K block typically
>> shouldn't force any existing pages out of RAM until someone
>> actually accesses the space.
>
> Actually, it's not allocating a big block, but rather 7,000
> NSHTTPCookie objects and 7,000 NSHTTPCookieInternal ones. So I
> think it's using real RAM.
>
> I'm embarrassed to say that when I ran ObjectAlloc again, no memory
> was used for cookies. I guess turning them off *did* work, and
> somehow that change (which was in a framework) didn't get
> recompiled into the app before I did my test (unless there's some
> other factor I'm not aware of). So perhaps the lesson here is that
> it's well worth using -setHTTPShouldHandleCookies:.
LOL, well at least it's solved!
And yes, if it's allocating 14,000 tiny objects, that is definitely
real RAM being consumed. :) -
On Aug 9, 2006, at 9:25 PM, John Stiles wrote:
> And yes, if it's allocating 14,000 tiny objects, that is definitely
> real RAM being consumed. :)
About 4 MB, counting the NSStrings that go with them.
--Michael
