Hi,
on and for OS 10.6.8 I am developing a single threaded Core Data (classical) music database. The model consists of eight (to-many, to-one and inversely) interlinked entities around a central "recording" entity. I am using independent managed object contexts for viewing and editing data (as well as for import and export). After saving from the editing context changes are propagated to the viewing context and the editing context is reset and torn down. The main table for data display shows most (if not all) of the data for each recording data set at one glance. The table is hooked up via array controller bindings, the controller preparing the total content of the database (currently about 38.000 data sets from a 9,3 MB MySQL store), data being filtered on the controller level for viewing. You may consider this a bad design decision, but please hold on. The problem is, that each search being executed raises the memory footprint by from 15 to as much as 250 MB or even more depending on the search. After a couple of searches memory consumption in Activity Monitor reaches GB levels, swap file sizes multiply and the system slows down. Now here comes the interesting part: While using the out-of-the box Allocations Instrument from Instruments.app, all is well. The live bytes size is at around 38 MB, rises to 45-50 MB when a search is executed, and sinks back to 38 MB. Activity Monitor at the same time shows a physical memory consumption of around 120 MB, which rises a couple of MBs according to the size of the results list and then also falls back to the standard level. I can execute dozens of searches under this setup with the memory footprint staying at a more or less constant level - which is what I would expect in the first place. 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. I tried an approach adapted from code described at http://stackoverflow.com/questions/3984222/core-data-avoiding-retain-cycles-in-to-many-relationships to refault. Logging the registered objects from the viewing MO context to the console proves that the majority of objects shows the expected faults. The interesting thing is that using or not using this code does not change anything. The same goes for disabling undo for the context in question. 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. Has anybody seen something like this? How could I try to debug or work around this phenomenon? The Core Data Instrument does not seem to provide anything relevant. The Leaks Instrument shows very small leaks here and there but not in my code and not remotely in the same size league. Static analysis returns no related result. Searching the web I found an interesting article about core data memory bugs on iOS http://finalize.com/2013/01/04/core-data-issues-with-memory-allocation/ but I have yet to try any of the techniques described there. I heard about Core Data memory handling being especially bad on 10.6 and much improved under 10.8, but moving to 10.8 is currently not an option. I am sure that changing my design, i.e. executing searches as real fetches from the store, or reimplementing this with a real database backend should lead to better performance, but this is a different issue and I'd rather avoid the latter. 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
