Re: Losing my memory - a caching problem?
Re: Losing my memory - a caching problem?
- Subject: Re: Losing my memory - a caching problem?
- From: Ken Ferry <email@hidden>
- Date: Tue, 17 Aug 2010 22:57:46 -0700
On Tue, Aug 17, 2010 at 1:05 PM, Stuart Rogers <email@hidden> 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 them in a bitmap, but you now
> have a redundant bitmap:
>
>
> Yes, I wanted to be sure I knew exactly what my bitmap format looked
> like. And yes again, I realised there was some redundancy there - I
> wasn't quite sure at the time I wrote it how to avoid that.
>
> You can directly draw the CIImage in the context created from the bitmap.
>
> This by itself is not likely to be your problem, but fixing this may have a
> side effect that fixes the problem. When you use -[NSBitmapImageRep
> initWithCIImage:], it basically calls -[CIContext createCGImage:fromRect:]
> using -[NSGraphicsContext CIContext]. The latter is possibly a long lived
> object, and the CIContext may be the location of caches.
>
>
> I think we're on the right track. I've cut out the redundant bitmap and
> although the problem remains, it's noticeably reduced. (One of my test
> sets contained 3500 images - previously it would chew through all 8GB,
> but with my replacement code I have over 2.5GB left with no extra swap
> files. This isn't good enough, but it's a good start.)
>
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" template.
If that fails, this suggests that the memory is allocated in an exotic way.
Instruments will catch malloc'd memory, but not mmap'd memory or direct
calls to vm_allocate.
You can try using tools like /usr/bin/vmmap and /usr/bin/allmemory to try to
see where the memory is going. If it really is exotic, though, it's
probably CoreImage. Last I was aware there _was_ some global caching in
CoreImage that was too aggressive in some circumstances, but things may very
well have changed. You might try bringing your problem to the quartz list.
-Ken
Cocoa Frameworks
>
> My bitmap code now looks like this:
>
> NSInteger pixelsWide = [ciImage extent].size.width;
> NSInteger pixelsHigh = [ciImage extent].size.height;
>
> NSInteger samplesPerPixel = 4;
> NSBitmapImageRep *bmpImgRep = [[[NSBitmapImageRep alloc]
> initWithBitmapDataPlanes:NULL
> pixelsWide:pixelsWide
> pixelsHigh:pixelsHigh bitsPerSample:8
> samplesPerPixel:samplesPerPixel
> hasAlpha:YES isPlanar:NO
>
> colorSpaceName:NSCalibratedRGBColorSpace bitmapFormat:0
>
> bytesPerRow:0 bitsPerPixel:0]
> autorelease];
> [NSGraphicsContext saveGraphicsState];
> NSGraphicsContext *ctx =
> [NSGraphicsContext graphicsContextWithBitmapImageRep:bmpImgRep];
> [NSGraphicsContext setCurrentContext:ctx];
> [[ctx CIContext] drawImage:ciImage
> atPoint:NSMakePoint(0,0) fromRect:NSMakeRect(0,0,pixelsWide,pixelsHigh)];
> [NSGraphicsContext restoreGraphicsState];
>
> The documentation for -[NSGraphicsContext CIContext] says that the
> CIContext
> only lives for as long as its owning NSGraphicsContext, so I'm assuming (!)
> that
> it'll be released when I pop the owning context with -restoreGraphicsState.
>
> (Also, it's unlikely that you want device RGB as the colorspace for the
> bitmap. If you want your results to be independent of the machine they're
> produced on, you need to be using device-independent colorspaces.)
>
>
> You're right - that was sloppy cut-and-paste on my part. I'm a bit hazy
> on colour spaces, but I've switched it to NSCalibratedRGBColorSpace.
>
> Thanks very much for your help, it's much appreciated.
>
> Stuart
>
>
_______________________________________________
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