On Wed, Aug 18, 2010 at 9:57 AM, Shawn Erickson shaw...@gmail.com wrote:
On Wed, Aug 18, 2010 at 3:45 AM, Stuart Rogers stuart.rog...@me.com
wrote:
On 18 Aug 2010, at 01:31, Ken Thomases wrote:
On Aug 17, 2010, at 7:26 PM, Shawn Erickson wrote:
When you say free I assume you mean the
On Tue, Aug 17, 2010 at 1:05 PM, Stuart Rogers stuart.rog...@me.com wrote:
On 17 Aug 2010, at 18:05, Ken Ferry wrote:
(1) I would focus your attention on CoreImage in this case.
(2) It is wonderful that you realized that if you want the bits in a
specific pixel format then you need to draw
On 18 Aug 2010, at 01:26, Shawn Erickson wrote:
... however if your application loads
file data (aka image data in your case) only once or it is unlikely
your application will load the same file data again in the reasonable
near future then you should look at disabling file caching of the
On 18 Aug 2010, at 01:31, Ken Thomases wrote:
On Aug 17, 2010, at 7:26 PM, Shawn Erickson wrote:
When you say free I assume you mean the free: number listed in
activity viewer for the system as a whole?
If so then what you are seeing is an expected result of the unified
buffer cache
On 18 Aug 2010, at 06:57, Ken Ferry wrote:
Did you say that the Object Alloc tool does not report the memory that is
being used? First verify that. You don't want to use the object alloc tool
from the leaks template, its config options are not appropriate. Start from
the Allocations
On 18 Aug 2010, at 01:26, Shawn Erickson wrote:
So in general you shouldn't worry about free RAM shrinking to a sliver
of total system RAM over time... however if your application loads
file data (aka image data in your case) only once or it is unlikely
your application will load the same
On 18 Aug 2010, at 12:50, Stuart Rogers wrote:
On 18 Aug 2010, at 01:26, Shawn Erickson wrote:
I think we have a winner! I've just implemented Shawn's suggestion
and it seems to solve my problem. I've just passed 9,695 image files
through my code's test phase (at 1.2MB apiece, that's
On Tue, 17 Aug 2010 23:00:02 +0100, Stuart Rogers said:
Have you tried using drain instead of release? That seems to be the
preferred way at this point, triggering GC collection if needed (I don't
know if your code is GC enabled, but if the library code is GC enabled,
then this will solve
On Wed, Aug 18, 2010 at 6:45 AM, Stuart Rogers stuart.rog...@me.com wrote:
I quite understand this, but the practice doesn't quite fit the theory.
If 'inactive' is effectively available as 'free' for all apps, then it should
be
available to my app. And yet, when 'free' drops to just a few
On Wed, Aug 18, 2010 at 3:45 AM, Stuart Rogers stuart.rog...@me.com wrote:
On 18 Aug 2010, at 01:31, Ken Thomases wrote:
On Aug 17, 2010, at 7:26 PM, Shawn Erickson wrote:
When you say free I assume you mean the free: number listed in
activity viewer for the system as a whole?
If so then
I'm having enormous difficulty keeping tabs on memory usage in my current
project. I'm happy that I'm not leaking anything - Build Analyse reports no
issues, and neither does Instruments (Object Allocations and Leaks). And yet,
when watching bulk memory usage I see my free RAM dropping like a
From: Stuart Rogers stuart.rog...@me.com
Date: August 17, 2010 6:10:45 AM EDT
To: cocoa-dev@lists.apple.com
Subject: Losing my memory - a caching problem?
I'm having enormous difficulty keeping tabs on memory usage in my current
project. I'm happy that I'm not leaking anything - Build
Hi Stuart,
Just a couple of quick notes:
(1) I would focus your attention on CoreImage in this case.
(2) It is wonderful that you realized that if you want the bits in a
specific pixel format then you need to draw them in a bitmap, but you now
have a redundant bitmap:
NSBitmapImageRep
On Tue, Aug 17, 2010 at 9:53 AM, Cem Karan cfkar...@gmail.com wrote:
SNIP
One dumb question; I see where you're putting images into an autorelease
pool, but I don't see you setting up or tearing down pools. Where are you
doing that?
Or, it could be much easier than I was saying and you
On 17 Aug 2010, at 18:05, Ken Ferry wrote:
(1) I would focus your attention on CoreImage in this case.
(2) It is wonderful that you realized that if you want the bits in a specific
pixel format then you need to draw them in a bitmap, but you now have a
redundant bitmap:
Yes, I wanted to
On 17 Aug 2010, at 18:07, Ken Ferry wrote:
On Tue, Aug 17, 2010 at 9:53 AM, Cem Karan cfkar...@gmail.com wrote:
One dumb question; I see where you're putting images into an autorelease
pool, but I don't see you setting up or tearing down pools. Where are you
doing that?
Or, it could be
On Aug 17, 2010, at 4:05 PM, Stuart Rogers wrote:
On 17 Aug 2010, at 18:07, Ken Ferry wrote:
On Tue, Aug 17, 2010 at 9:53 AM, Cem Karan cfkar...@gmail.com wrote:
One dumb question; I see where you're putting images into an autorelease
pool, but I don't see you setting up or tearing down
On 17 Aug 2010, at 21:36, Cem Karan wrote:
On Aug 17, 2010, at 4:05 PM, Stuart Rogers wrote:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
...
[pool release];
Have you tried using drain instead of release? That seems to be the
preferred way at this point, triggering
On Aug 17, 2010, at 5:20 PM, Stuart Rogers wrote:
On 17 Aug 2010, at 21:36, Cem Karan wrote:
On Aug 17, 2010, at 4:05 PM, Stuart Rogers wrote:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
...
[pool release];
Have you tried using drain instead of release? That seems to
On Aug 17, 2010, at 2:32 PM, Cem Karan wrote:
Mmm, my question is, what about Apple's code? I'll be the first to admit, I
don't know enough about what goes on under the hood, so what I'm about to say
may be very, very wrong (anyone out there that knows better than me, here is
your cue to
On Aug 17, 2010, at 5:37 PM, Greg Parker wrote:
On Aug 17, 2010, at 2:32 PM, Cem Karan wrote:
Mmm, my question is, what about Apple's code? I'll be the first to admit, I
don't know enough about what goes on under the hood, so what I'm about to
say may be very, very wrong (anyone out there
On Tue, 17 Aug 2010 22:20:55 +0100, Stuart Rogers said:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
...
[pool release];
Have you tried using drain instead of release? That seems to be the
preferred way at this point, triggering GC collection if needed (I don't
know if
On 17 Aug 2010, at 22:48, Sean McBride wrote:
On Tue, 17 Aug 2010 22:20:55 +0100, Stuart Rogers said:
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
...
[pool release];
Have you tried using drain instead of release? That seems to be the
preferred way at this point,
On Tue, Aug 17, 2010 at 3:10 AM, Stuart Rogers stuart.rog...@me.com wrote:
I'm having enormous difficulty keeping tabs on memory usage in my current
project. I'm happy that I'm not leaking anything - Build Analyse reports no
issues, and neither does Instruments (Object Allocations and Leaks).
On Aug 17, 2010, at 7:26 PM, Shawn Erickson wrote:
When you say free I assume you mean the free: number listed in
activity viewer for the system as a whole?
If so then what you are seeing is an expected result of the unified
buffer cache maintained by the system (since you say private memory
25 matches
Mail list logo
