I've become frustrated enough to beg for some insights from the mob. I have an application that using MapKit, on tap it shows a thumbnail, and on tap of the thumbnail it shows a photo gallery of images. All the images are using SDWebImage. I've looked at my allocation tables and see that the map alone is using a ton of memory. It peaks at around 60mbs, kind of crazy. When I open the gallery it drops to around 40/35mbs. I can look at one gallery just find, but as soon as I open up a second gallery and start scrolling it crashes, even though the memory use is around 35mbs.
My first attempts at combating this where to purge the WebImage cache on didReceiveMemWarning, second was to actually remove the map and all annotations. The app is using ARC.
Here is the question... How can I fix this? Get this to stop with the memory crash. Any help?
Crash Report
Free pages: 1188
Active pages: 6757
Inactive pages: 4192
Throttled pages: 89007
Purgeable pages: 0
Wired pages: 26699
Largest process: DbConnect
Processes
Name <UUID> rpages recent_max [reason] (state)
accountsd <e6ceba0e6e053a3ea02d0a916903cff8> 284 284 [vm] (daemon) (idle)
installd <117f65beb8cb38da8e0844256c65e402> 301 301 [vm] (daemon) (idle)
networkd_privile <cd5f76fd767c31428f411ecf03540546> 115 115 [vm] (daemon) (idle)
lsd <566268cf717b335e98ddba10ca9315ab> 265 265 [vm] (daemon) (idle)
MobileMail <e07ca7a7280736c7bf301451f89d1c02> 1022 1022 [vm] (resume) (continuous)
MobilePhone <51866c9bc9f93c9d8526e8acf9efc64c> 998 998 [vm] (resume) (continuous)
tccd <2778744d99a530c9a7d5e57a19b60008> 161 161 [vm] (daemon)
DbConnect <f628b610fcc23c559f2a96959ac78b15> 21523 21523 [vm] (frontmost) (resume)
ptpd <096297a7a40f318290a972274cc44d87> 591 591 (daemon)
wifid <72eda25ccdd737a79d6cd172e9bf99a5> 615 615 (daemon)
syslogd <da215e2d3de133bf8f52590727b9bdfe> 270 270 (daemon)
aosnotifyd <47126a998bb5308f9d5cbe028dc47d60> 447 447 (daemon)
locationd <137100f254373daeb894f665c413f8b0> 1023 1023 (daemon)
iaptransportd <9b3cf56b4db13761bbd8ac2e0ff099be> 242 242 (daemon)
dataaccessd <abc7f74d5d683d4c9a04e7ade5b1126b> 1835 1835 (daemon)
mediaserverd <af72564bf8713fb8b16ee64c5ee85568> 1645 1645 (daemon)
SpringBoard <bd1d77d154ef3dffbb53d89337c8a08f> 4057 4057
backboardd <e1dc74434e0e3938b17ff0f7ad85d138> 9463 9463 (daemon)
lockdownd <a123aa04ddf83a5fae8e5bc08f0b5771> 260 260 (daemon)
powerd <63673a83ac9c3cf98fdc75df8ba70fd0> 156 156 (daemon)
mDNSResponder <1e651badfb7033a68a73a667ec480a08> 247 247 (daemon)
UserEventAgent <7ee3410c25e4372d84e93318fe42696b> 534 534 (daemon)
syncdefaultsd <a18b8aeea66e3ebb9ab0d54e55c1b9d1> 263 263 (daemon)
DTMobileIS <0e7e02810e383e2c9ebc212d94b6044f> 0 0 (daemon)
mobile_profile_j <9e3c8e8611da3c68af7e5511500256de> 194 194 (daemon)
springboardservi <438ae856a1c039a197e6987a99a8b9b6> 0 0 (daemon)
syslog_relay <ee47daae952636649230d38b3dc5c2e0> 0 0 (daemon)
afcd <3bd960d39c9f3972a10923db0e687b4a> 152 152 (daemon)
notification_pro <08df322fbe7739199f78852a511169ef> 136 136 (daemon)
absinthed <b5e167e1b2dc3bf9b5f704afb30aed5f> 105 105 (daemon)
filecoordination <28ca39773e933ed2aa92c117c661d056> 164 164 (daemon)
apsd <5be27dc5ea5234319bc4b47380e42174> 342 342 (daemon)
distnoted <699b8253736233b29180419f139e8c01> 121 121 (daemon)
networkd <49064febbe553338bd98051399022da4> 182 182 (daemon)
aggregated <c5a375854c3c31d59548ab53ea86d194> 93 93 (daemon)
fseventsd <3ea853cb95de3aa48972aa42637af69a> 344 344 (daemon)
BTServer <af0150d5085e326598edff072a23d146> 243 243 (daemon)
imagent <2b64c6111aa63b179a15afd6a76a6696> 387 387 (daemon)
configd <b6a4d70640b63e8f82e0e9f3d6ee2bb9> 510 510 (daemon)
fairplayd.P106 <c5ca0bc497013131a5c17a89fdedcd82> 175 175 (daemon)
geod <d180dd46c4bd3ffbb856b5eb8589a45c> 296 296 (daemon)
CommCenter <cb877b4411ee3a348ec44c02ff3da38d> 608 608 (daemon)
notifyd <67a17b0c297e3785a9e09b8e72f3636a> 188 188 (daemon)
Allocation Graph
Allocation Table
I figured this out on my own. In case any one else runs into this I'll explain. The solution was actually very simple. I was using a CocoaPod called UIPhotoGallery. That was the problem. Something in it was causing the memory not to be released. I didn't bother trying to fix it. Instead I found another one that worked better. We're using MWPhotoBrowser now (https://github.com/mwaterfall/MWPhotoBrowser). Works like a charm and it wasn't too difficult to setup.
In case anyone else is looking for a gallery library I tried:
ios-KRImageViewer
Nimbus
GVPhotoBrowser
UIPhotoGallery
All of which were either too complicated, lacked documentation, or didn't work good. I hope this helps others.
Related
I've built this table:
s_male Values
0 1
hs_name1 AVERAGE of sat_composite STDEV of sat_composite COUNT of s_lasid AVERAGE of sat_composite STDEV of sat_composite COUNT of s_lasid
Hope High School 986 600 639 979 630 579
James High School 837 568 473 830 612 428
Juniper High School 789 525 538 722 577 466
Kennedy High School 531 468 314 523 484 239
King High School 683 540 275 619 569 258
Lincoln High School 842 538 354 933 534 279
Meadowbrook High School 484 517 292 484 507 274
North Falls High School 1056 531 590 1046 547 564
Orange High School 905 597 555 828 619 526
Polk High School 680 569 567 691 568 501
South Falls High School 898 602 488 904 584 461
Upper Hills High School 457 491 349 431 490 248
Washington High School 795 609 482 818 635 401
Grand Total 801 585 5916 796 603 5224
Alos pictured here:
I now want to calculate if the average SAT_composite score for women (s_male=0) is statistically different than for men (s_male=1).
I've been trying to figure this out and I am a little lost. Any help would be greatly appreciated.
What you're looking for is just a regular t-test. In google sheets the syntax is:
=TTEST(B2:B8,C2:C8,2,2)
That will give you the p value associated with the test
Arguments:
Range for male scores
Range for female scores
How many tails? 1 or 2
Type of t-test. This choice is important and depends on whether certain assumptions have been violated (primarily independence and homoscedasticity)
I would agree with Toms suggestion in the comments about going back to the raw data as you'll be able to better model your data (in your example you've already collapsed across schools by calculating means, which loses information)
I've run into a bit of a delima. I've been doing some 3D scanning and would like to convert .xyz file attained from the scanning process to LibSVM format.
the .xyz file would look like this:
31 423 578
34 423 582
42 423 621
43 423 650
47 423 668
48 423 677
80 423 670
84 423 589
86 423 602
88 404 553
89 403 583
89 404 664
90 393 673
90 396 563
90 397 607
90 403 624
90 404 666
91 409 517
91 411 579
And LibSVM format is like this:
<label> <index1>:<value1> <index2>:<value2> ...
What is to be considered before going about this process? What exactly would my label and index value(s) be? I'm sure value1 would equal the x coordinate. (Please correct me if I'm wrong).
Any demonstration code to give me a gist of the process would certain be appreciated. But words are great.
I have an app which is crashing with
Terminating in response to backboardd's termination
Here the app crashes and even the Springboard. You can see the Apple logo for a short time and it seems that the device is rebooting.
This is taken from the device log
Incident Identifier: AECC8A4C-B6E0-47B5-A2DD-C3A367107087
CrashReporter Key: 26d2ecafff1bd02c1e774f056b3d20c8b03241c3
Hardware Model: iPad4,2
OS Version: iPhone OS 7.1.2 (11D257)
Kernel Version: Darwin Kernel Version 14.0.0: Thu May 15 23:17:54 PDT 2014; root:xnu-2423.10.71~1/RELEASE_ARM64_S5L8960X
Date: 2015-08-17 16:49:06 +0200
Time since snapshot: 117 ms
Free pages: 114466
Active pages: 5397
Inactive pages: 67177
Speculative pages: 258
Throttled pages: 0
Purgeable pages: 0
Wired pages: 52014
File-backed pages: 43687
Anonymous pages: 29145
Compressions: 4016283
Decompressions: 516269
Compressor Size: 10655
Uncompressed Pages in Compressor: 30459
Largest process: backboardd
Processes
Name <UUID> rpages recent_max fds [reason] (state)
CloudKeychainPro <0b4f59ba89df38039892ce8ad342a013> 152 152 100 (daemon) (idle)
syslog_relay <1dc57ae8a60c3654bbf327c16a01d551> 88 88 100 (daemon) (idle)
storebookkeeperd <83b2723af35f32b3beafb32abd677b7b> 509 509 100 (daemon) (idle)
adid <707928b1d97336d5beb5291562421efd> 130 130 200 (daemon) (idle)
aosnotifyd <6e3b66f6dad73af08e7f49db92efc045> 559 559 100 (daemon) (idle)
installd <4e0b7c36602737a3b0dd0bd733eb4378> 195 195 100 (daemon) (idle)
mobileassetd <8574a112afc337638edcd9ac0404f1c6> 1531 1531 200 (daemon) (idle)
gamed <943623c4259f306e93b97ce614edf89e> 785 785 100 (daemon) (idle)
afcd <208713527dc0315a9198e99db64d3cf1> 119 119 100 (daemon) (idle)
timed <294a840542e13dca88162e0fbe687f94> 244 244 100 (daemon) (idle)
keybagd <92fe9694044a3f4387459afb0f88a705> 114 114 100 (daemon) (idle)
MobileGestaltHel <f20bac36fcac32628ad30c2da33effd8> 161 161 100 (daemon) (idle)
geod <fb5d1b37f6703663818bd883ed500ea6> 263 263 100 (daemon) (idle)
softwareupdatese <5cfe93434a573beeb6ef41304af4a352> 949 949 200 (daemon) (idle)
assetsd <fd2bd931098b341f846302c614cc5ae8> 471 471 200 (daemon) (idle)
IMDPersistenceAg <9bd313f498a13e61b54d2ae6ec19ea2c> 220 220 100 (daemon) (idle)
accountsd <ee22a71a12f933179729608a16b45094> 622 622 100 (daemon) (idle)
itunesstored <3768d425f2103c209fdd1722b8f5acaa> 1171 1171 100 (daemon) (idle)
securityd <d79d9800981f3cedad0ca6975c9b9f0c> 602 602 100 (daemon) (idle)
mediaremoted <336797e58ac036298bdcdd5d558c227c> 245 245 100 (daemon) (idle)
coresymbolicatio <0b798227409d39c3b23e63bf4bcb820d> 89 89 100 (daemon) (idle)
DuetLST <06955a348ea2371e8d7ec43936431caa> 452 452 100 (daemon) (idle)
sandboxd <e75c30438fb73c20a67dd096f80352e3> 130 130 100 (daemon) (idle)
networkd_privile <5bd47a1c3d12302ea6d78a52cf4ab0a4> 90 90 100 (daemon) (idle)
routined <6dbb51d76fbb3d79aa6ea9f3c16c608f> 383 383 100 (daemon) (idle)
lsd <f2a08944163c31b9a8fd7f3a43ceacb0> 261 261 100 (daemon) (idle)
assistantd <5b53d51bff1236baa617758c37d4f862> 418 418 100 (daemon) (idle)
xpcd <8b704605eb243a10bfe026138c1908cd> 292 292 100 (daemon) (idle)
librariand <c8d851b111f0324e8de6eaf46ac108d0> 380 380 100 (daemon) (idle)
MobileMail <f359afe7da513629b0a6b8aa32a0b90b> 1073 1073 100 (resume) (continuous)
tccd <e37a9bd3403c34adbbd9d75e9022240a> 179 179 100 (daemon)
kbd <2669fa0ab11a356fbd9482881637e730> 595 595 100 (daemon)
MyCrashingApp <25870f37b79d36e584a2e7c6db2717f5> 176783 176783 100 [per-process-limit] (frontmost) (resume)
ptpd <606d697050af3b23a54e4d75eafef6c0> 605 605 200 (daemon)
identityservices <1695cbd72da83c4c87c568bd53a01d24> 442 442 200 (daemon)
wifid <c0ed3dbc8d7f329489a04faf460c027c> 411 411 200 (daemon)
syslogd <88667a0c3dc6398e9b1c6a0c5a5d8f24> 187 187 200 (daemon)
powerd <1a8551a962783aa9899be0e55a9c1e58> 152 152 200 (daemon)
locationd <3480b01585f039ca9c45ecc16928d8b0> 1139 1139 200 (daemon)
imagent <5a1a726d45e033f2bea34c3ae04e817c> 300 300 200 (daemon)
dataaccessd <ae41b26410e3338ba33e337fb5439069> 1131 1131 100 (daemon)
apsd <f96e01aab90637b0822aff105bf78d70> 578 578 200 (daemon)
mediaserverd <6c2cee9548813cea95bf5548d3411408> 1087 1087 100 (daemon)
iaptransportd <009cdd0e53bf34829b6a8b69e0ca49bf> 260 260 200 (daemon)
mDNSResponder <090a345fd6e13f52b156a3eb9a0e78ee> 220 220 100 (daemon)
sharingd <63eae5785eac326987c89d771258ebf8> 571 571 200 (daemon)
SpringBoard <ccb584e84f2f3005a9c20897fdb783dd> 6419 6419 100
backboardd <3085386f5f99357aa9f055e0fb79b827> 181876 181876 100 [per-process-limit] (daemon)
fseventsd <8b8df4c7b46b3dcfb4e1b1d8a6cbb686> 1203 1203 50 (daemon)
lockdownd <6bdd33b3920236808292915812d386c8> 344 344 50 (daemon)
wirelessproxd <41e0cf822ff33124b3c3949cedce7fd2> 196 196 50 (daemon)
configd <2123dc8c1e103375aec0905809a8d38e> 646 646 50 (daemon)
aggregated <178824f7adc231249e9e341c03c36855> 590 590 100 (daemon)
fairplayd.A2 <9948545906083ff9962c310943eb34de> 148 148 100 (daemon)
BTServer <5540f7e4ecd535b9a48b50258130dbd1> 404 404 100 (daemon)
distnoted <a237d6a85cae3c409b914ccb8e5b63f1> 182 182 100 (daemon)
UserEventAgent <f9cb9c166628392a9d190acff16950b9> 995 995 100 (daemon)
filecoordination <4d26113e2e3d3b21832eb866679edf38> 251 251 200 (daemon)
itunescloudd <266cb30204a039d5b2f5aba30cf05015> 1044 1044 100 (daemon)
DTPower <79ced86c61333b6aaa2460276eb0b8eb> 282 282 200 (daemon)
ubd <b54681e3319e36b48148ab2026ebf542> 655 655 200 (daemon)
eapolclient <a5ac733ff23936b4ab05dde3fd5fb17b> 173 173 50 (daemon)
afcd <208713527dc0315a9198e99db64d3cf1> 134 134 200 (daemon)
notification_pro <293150329f1d317c99a6c5fa2e25963a> 140 140 200 (daemon)
DTMobileIS <100bfdacf0a63ae9ab08b27669042812> 2292 2292 200 (daemon)
LeakAgent <30856ea2089a3263aaf27fd9faee406d> 3520 3520 100 (daemon)
networkd <7262086478d63812ae40c561e8e1acbf> 509 509 200 (daemon)
WirelessCoexMana <1e096a90f671399d975e83beb668eb91> 151 151 100 (daemon)
touchsetupd <9d37501e59f13ca1b1577435bdb43a9f> 197 197 200 (daemon)
CommCenter <e5c6b5b1f64833de93bd22bbe135c9b6> 1196 1196 100 (daemon)
notifyd <1d555aa3d08c336294a38d9c134dca00> 319 319 100 (daemon)
**End**
I can't see any hint where the problem lies. The app crashes when I push a new view controller on the navigation stack. On this view controller there is a full screen label. The error also happens after opening and closing the view controller 40 times or so.
Similar questions have different hints:
Too much memory from OS requested
Too many animations/didn't queue animations
Use instruments
Memory warning
So the memory management problem is the most likely one. I tried to use Instruments, but Leaks didn't give me some useful hints (only some malloc and auto release pool with 48 kB max. - seems a OS bug). Also Zombies and Activity Monitor aren't helpful. Using Instruments makes everything really slow.
Only with allocations I saw the UILabel subclass is taking too much space. Every time the new view controller is created, the memory increases by 10 MB (persistent bytes) and that is only the label!
Too make things more complex I'm using Xamarin.iOS. The garbage collector isn't deallocating the view controller when it popped off the navigation controller. But it does it at some time. I think when the system needs more space (nothing left) than the GC kicks in. I could reproduce this behavior in a simple project with my big sized label.
Why does the garbage collector doesn't kick in? I get memory warnings but I can't release something. Normally the view controller and its subviews should get deallocated when they are unloaded from the navigation controller.
When I know why my app is crashing I can do something against this. How can I debug this issue?
Edit:
Now I tried to crash the app on an iPhone. Here you can find the debugger output and here the device log. Again it seems that I'm running out of memory. But my only hint is still the label, because none of the tools can tell me exactly where the problem lies.
I made the following steps to reduce the memory pressure:
used separate class for my custom EventArgs (before: in view controller)
no anonymous function for button in UINavigationBar
no anonymous funciton for UIActionSheet
rewrote EventHandler in that way that I subscribe to them in viewWillAppear and unsubscribe in viewWillDisappear (most of the time)
added Target for UIGestureRecognizer in viewWillAppear and removed it in viewWillDisappear
removed cycle between view controller and datasource through using a WeakReference
I made some checks and it now seems to work. For testing if a view controller is deallocated or not use this:
protected override void Dispose (bool disposing)
{
Console.WriteLine (String.Format ("{0} controller disposed - {1}",
this.GetType (), this.GetHashCode ()));
base.Dispose (disposing);
}
Through this and commenting the things out I were able to detect the reference cycles. I hope I fixed all problems. The main problems were the EventHandler.
For solving my issue the following questions belong to it:
Clicked handler not executed for UIButton in UIBarButtonItem
How to break reference cycle between view controller and data source
Through presenting new view controller viewWillDisappear on parent is triggered where I unsubscribe from the events
RemoveTarget from UITapGestureRecognizer
Add/remove EventHandler for UIBarButtonItem
The following links were helpful in resolving the memory issue:
Memory and Performance Best Practices
Is this a bug in MonoTouch GC?
Memory Management Pitfalls in Xamarin iOS - Introduction + Part 1 + Part 2
Weak Event Pattern in MonoTouch
iOS Memory Managment by Rodrigo Kumpera (Xamarin)
My App Crashed, Now What? – Part 1 + Part 2
signal
I'm experiencing a crash on my iPad which I think is related to my app just running out of memory, however I can't seem to glean any information about the crash itself in order to resolve it. The app uses ARC.
The app spends about 20 minutes downloading data from our server and populating a Core Data model. Around the 20 minutes mark, the app crashes.
The device isn't running out of space - in fact the downloaded content takes up just a hundred megabytes. I'm using only a single managed context object (nb. I'm not saving the context until the entire data set has downloaded).
When I run in debug with an exception breakpoint enabled, I app just crashes without breaking and without displaying any type of warning or error.
Any advice on how to track down the problem? From the crash log below, does it look like the app is just running out of memory, or might it be
Here's the crash log:
Incident Identifier: A619465F-2E85-4BBC-BBE7-2330D4700FB8
CrashReporter Key: 6fa0c5a4f6cbeaf7a98e6c0e9ad8be6b27789039
Hardware Model: iPad2,2
OS Version: iPhone OS 6.0.1 (10A523)
Kernel Version: Darwin Kernel Version 13.0.0: Wed Oct 10 23:29:31 PDT 2012; root:xnu-2107.2.34~2/RELEASE_ARM_S5L8940X
Date: 2013-04-27 09:53:43 +0200
Time since snapshot: 152 ms
Free pages: 934
Active pages: 3455
Inactive pages: 1821
Throttled pages: 103117
Purgeable pages: 0
Wired pages: 18795
Largest process: GreaseBook
Processes
Name <UUID> rpages recent_max [reason] (state)
MobileMail <27df582d2bed3501834661269810ad98> 3928 3928 [vm] (continuous)
kbd <24d58ac14ed3340380492fef46eac29d> 574 574 [vm] (daemon)
tccd <eb5ddcf533663f8d987d67cae6a4c4ea> 281 281 [vm] (daemon)
GreaseBook <2f5df68a7078386298eadbb24ebbdb33> 84210 84210 [vm] (frontmost) (resume)
ptpd <0cac6936ffeb362d98eb8073af935d21> 992 992 (daemon)
mediaserverd <bdc35c073fe134b9a39b96342a80159e> 1082 1082 (daemon)
syslogd <cbef142fa0a839f0885afb693fb169c3> 281 281 (daemon)
locationd <4bee615548dd33f48e18bfed4296f05d> 1675 1675 (daemon)
wifid <a243b2fcde2537159660b3ee7e809df4> 649 649 (daemon)
aosnotifyd <01901b13681f3582b5bfbe53504d08d6> 480 480 (daemon)
dataaccessd <117e4e475b14305982f52484564cfbc7> 1319 1319 (daemon)
iaptransportd <f784f30dc09d32078d87b450e8113ef6> 241 241 (daemon)
SpringBoard <0e3571e8067533e2811a6d444f10a349> 4058 4058
backboardd <a9b5346126a939dfb0920a4bbc48201b> 6057 6057 (daemon)
imagent <d15f873abdd233f0a34d77a7d36e9e0f> 329 329 (daemon)
mDNSResponder <3e557693f3073697a58da6d27a827d97> 283 283 (daemon)
UserEventAgent <6edfd8d8dba23187b05772dcdfc94f90> 589 589 (daemon)
syslog_relay <45e9844605d737a08368b5215bb54426> 0 0 (daemon)
CVMServer <3ec015e0150d341a929ebbbc45f4c8ac> 104 104 (daemon)
afcd <b0aff2e7952e34a9882fec81a8dcdbb2> 165 165 (daemon)
notification_pro <845b7beebc8538ca9ceef731031983b7> 203 203 (daemon)
filecoordination <fbab576f37a63b56a1039153fc1aa7d8> 195 195 (daemon)
distnoted <a89af76ec8633ac2bbe99bc2b7964bb0> 132 132 (daemon)
apsd <d0e432fd45023d629ffb305b7e79d7fb> 403 403 (daemon)
aggregated <cd70154f955c31bbab58bf5f0acd3acd> 108 108 (daemon)
networkd <b24547cbe04b3e94a4bd406e586cdf8a> 222 222 (daemon)
BTServer <f57113a7cc2c33678ee832bc088276be> 356 356 (daemon)
configd <4245d73a9e96360399452cf6b8671844> 576 576 (daemon)
fairplayd.K94 <1a5f575df8f4368db1eae7ba3da11150> 270 270 (daemon)
fseventsd <996cc4ca03793184aea8d781b55bce08> 362 362 (daemon)
powerd <2d2ffed5e69638aeba1b92ef124ed861> 198 198 (daemon)
securityd <c35e701a5aab3968ae8d93ef8db02e07> 159 159 (daemon)
lockdownd <481275a4062931708a7440ff0f73f229> 495 495 (daemon)
CommCenterClassi <c10fa2a1b7673e1ab14e6ecd11b9b7e7> 557 557 (daemon)
notifyd <51c0e03da8a93ac8a595442fcaac531f> 199 199 (daemon)
**End**
When downloading large data sets into core data, you need to account for lots of things. When it comes to memory management, the more popular issues are described below.
First and foremost, you need to save frequently, which allows you to purge the memory from the NSManagedObjectContext (aka MOC). At any time, you can see what objects the MOC has, by looking at the registeredObjects property of the MOC.
Normally, when you save a MOC, any objects that do not have a strong reference to them are removed from the MOC. Again, you can check after saving by looking at the registeredObjects. However, if you have relationships in your model, then the objects will contain strong references to each other, which creates a retain cycle. Thus, the objects will never be released until the retain cycle is broken.
You break retain cycles in a MOC by using refreshObject:object mergeChanges:NO. You can blow away all objects by calling reset but that is rather draconian, and you need to make sure you do not hold any references to managed objects when you do that.
Even if you don't have retain cycles between your managed objects, you could still be inadvertently retaining objects that you will never use again. This is where, even though you are using ARC, you still need to understand some memory management rules. Specifically, auto released objects. They will get automatically released, but not until the autorelease pool reclaims objects.
Thus, you should wrap your operations in your own autorelease pool. This is very simple:
#autoreleasepool {
// Unless you hold references elsewhere, objects allocated in here will be
// auto released when this scope ends.
}
If you have a thread doing your downloading, and you use a MOC of NSPrivateQueueConcurrencyType, the block you pass to performBlock gets automatically wrapped in an autorelease pool.
I've got a datafile with some values:
-55 471 485 500
-50 495 510 524
-40 547 562 576
-30 603 617 632
-20 662 677 691
-10 726 740 754
0 794 807 820
10 865 877 889
20 941 951 962
25 980 990 1000
30 1018 1029 1041
40 1097 1111 1125
50 1180 1196 1213
60 1266 1286 1305
70 1355 1378 1402
80 1447 1475 1502
90 1543 1575 1607
100 1642 1679 1716
110 1745 1786 1828
120 1849 1896 1943
125 1900 1950 2000
130 1950 2003 2056
140 2044 2103 2162
150 2124 2189 2254
When I call the following gnuplot script:
set terminal latex
set output 'foo.tex'
unset key
set format "%g"
set autoscale
set xlabel "Temperatur an $R_1$ [$^{{\degree}C}$]"
set ylabel 'Ladezeit [$ms$]'
f(r) =(log(1/3)*r*(47*(10e-6)))*-1
plot [-55:150] [0:3] '/some/path/res/kty_81-121.dat' using 1:(f($3)) with lines
gnuplot spits out a rather general error warning: Skipping data file with no valid points. After hours of doing research about this problem I have still no answer.
Does someone know how to fix this?
When divide integer with integer, gnuplot automatically cast the output into integer. Thus, the argument of the log function becomes zero (i.e. int(1/3) = 0), and became -inf. Change the function as below.
f(r) =(log(1.0/3.0)*r*(47*(10e-6)))*-1