Fritz, thanks for your reply.
(It looks like non of your posts made it to the list, I only received your private copies. Maybe you are inadvertently sending from an account not registered with the list?) Am 16.07.2013 um 02:43 schrieb Fritz Anderson: > On 14 Jul 2013, at 5:45 AM, Peter <magn...@web.de> wrote: > >> When executing the identical sequence of searches with Instruments not being >> involved, the memory consumption increases single-mindedly and (depending on >> the number of hits for the query) after a couple of searches reaches the 1 >> GB level, ever growing from there. >> >> On the other hand, Instruments.app's memory footprint increases steadily >> while running but not in the same degree as my app's. Don't know if this is >> normal. Should be. > ... >> The bottom line is: My app seems to behave very nicely while under >> surveillance of Instruments.app, but not on its own. Memory seems to get >> released while under surveillance, but not when not. > > I'm inferring this from your question, but I want to be sure: How are you > determining that your app's memory footprint is increasing when Instruments > isn't attached? From Activity Monitor? Don't do that. > > Activity Monitor tells you how much virtual memory your app has touched at > one point or another. It says nothing about whether all of that memory is > taken up by live objects, nor whether the pages for the former objects' > addresses are still in RAM. It also includes the size of shared memory > assets, like system libraries, that are going to be in RAM (or paged out) > anyway, for other processes to use. > > "Real Private Memory" is the closest thing to what you want, but even that > isn't what you mean. Trust Instruments. You are right and then not quite. The explanation proved to be simple (and my investigation efforts to be insufficient, thus making a fool of myself): I ran my app in the debugger of Xcode 3.2.6. This debugger quite obviously has a severe memory handling bug when Core Data is involved. The simple difference to running with Instruments is that in that case it does not seem to go through the debugger. So - of course - Instruments did nothing to remedy an alleged Core Data memory issue, but simply prevented my app to fall prey to the memory handling bug in the debugger - behind my (ignorant) back. Or so at least it seems to be now. (I am in the habit to run all my self-developed apps constantly in the debugger to be able to track down problems right when they happen.) When I run a deploy built from the Finder, the app no longer shows any signs of exceeding memory consumption and on top of that it is quite a bit faster. And yes, I used Activity Monitor do determine the app's memory footprint when Instruments was not attached (I had no choice not to, since the problem manifested itself only when Instruments was NOT attached - is there any better way?). I did in fact know that I should not trust Activity Monitor's memory data in terms of quantity. But in this case I had absolutely no doubt to trust it in terms of quality: As mentioned in my initial post, running my app as single and only user application I could see my swap file sizes double and then triple again to multi-GB sizes (on a machine with 12 GB built in memory where I normally see swap sizes of a couple of 100 MB) and I could see the memory footprint in Activity Monitor increase single-mindedly, never falling a single MB, the swapping activity increasing and the machine becoming more and more unresponsive. Given these circumstances I felt myself entitled to put some confidence into Activity Monitor's data, even if only in terms of quality. The problem was manifest and intolerable. Certainly it was not that Activity Monitor's bad data seemed to create a non-existant problem. When launching my app from the Finder, Activity Monitor now presents values from between 45 to 120 MB as the physical memory footprint, the value being in constant fluctuation depending on the state of the app. For me this proves that even if one is not to trust Activity Monitor in terms of quantity, there is no reason not to believe it in terms of quality, especially in terms of change over time. But Instruments doubtlessly is the tool of choice if you want to get exact data. My bottom line: The debugger in Xcode 3.2.6 under OS 10.6.8 has severe memory handling problems related to Cora Data - so luckily this at heart is not a Core Data issue but a debugger issue. Beware! Peter _______________________________________________ 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
