CPU sampling and +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:]
Hello, I'm sampling an iPhone app to detect any bottlenecks in performance. Interesting thing is that, from the first use of an NSURLConnection the following method will appear on Instruments: +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] And it's constantly running, even when the app is stopped (screenshot: http://1wwj.sl.pt). I'm guessing that when using a NSURLConnection the framework spawns a new thread and creates a runloop for it, this runloop just like the runloop on the main thread is constantly running even when I'm no longer using any NSURLConnection. Is my guess correct? Does this have any effect performance wise? Regards, Paulo Andrade___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CPU sampling and +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:]
Hello, I'm using the CPU sampler template. Here (http://1wzi.sl.pt) is a sample of a very simple run to prove my point. Here's how I collected it: - Start the app and let it fully launch (it does a few request at boot) - Attach instruments with the CPU Sampler template - Let it run for 30 seconds and not touch the iphone You'll see that the time is equally divided between +[UIApplication run] and +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] Please let me know if you have any other ideas that could explain this. Thanks a lot Paulo Andrade On Nov 13, 2009, at 4:40 PM, Joar Wingfors wrote: > > On 13 nov 2009, at 04.36, Paulo Andrade wrote: > >> I'm guessing that when using a NSURLConnection the framework spawns a new >> thread and creates a runloop for it, > > > That sounds about right. I could also see that the framework might choose to > keep this thread around after you've finished using it (in case you need it > again later). > > >> this runloop just like the runloop on the main thread is constantly running >> even when I'm no longer using any NSURLConnection. > > > I don't believe this to be the case though. When not handling any input > sources (sending / receiving data), I'd expect for this run loop (just like > the run loop for the main thread) to be "parked", not consuming any (or at > least not basically any) CPU. > > How are you running your CPU profile (what is the configuration you're using > when launching Instruments), and how are you filtering your data after > collecting the sample? If you want more feedback, upload the whole sample > instead of a screenshot next time. > > j o a r > > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CPU sampling and +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:]
Thank you both. I have finally understood what's going on :). On Nov 15, 2009, at 7:19 AM, Joar Wingfors wrote: > > On 14 nov 2009, at 03.20, Michael Ash wrote: > >> On Fri, Nov 13, 2009 at 1:28 PM, Paulo Andrade wrote: >>> Hello, >>> >>> I'm using the CPU sampler template. >>> >>> Here (http://1wzi.sl.pt) is a sample of a very simple run to prove my point. >>> >>> Here's how I collected it: >>> - Start the app and let it fully launch (it does a few request at boot) >>> - Attach instruments with the CPU Sampler template >>> - Let it run for 30 seconds and not touch the iphone >>> >>> You'll see that the time is equally divided between +[UIApplication run] >>> and +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] >>> >>> Please let me know if you have any other ideas that could explain this. >> >> The CPU sampler in Instruments does not distinguish between a thread >> which is actively running (and taking up CPU time) and a thread which >> is sleeping (and taking no CPU time). This does not make it very >> useful. I recommend using Shark instead. > > > Michael: > > Sometimes you don't care about sleeping threads, sometimes you do. And in > fact, Shark offers both modes: [1] Time Profile, and [2] Time Profile (All > Thread States). The second mode, Time Profile (All Thread States), works in > the same way as the CPU Sampler in Instruments. > > If you're investigating what is clearly a CPU bound problem, then you > probably aren't as interested in sleeping threads, and in that case the Time > Profile would work well (given that it has lower overhead and provides finer > granularity). The drawback with the Time Profile is that it doesn't even show > sleeping threads in the report (only active threads show up). This can be > surprising (what, no main thread?!), and you might also miss important clues. > > If you, on the other hand, are not quite sure what you're looking for yet, or > if you know that you're interested in blocking operations, then Time Profile > (All Thread States) in Shark, or the CPU Sampler in Instruments, probably > would be better. > > Paulo: > > You had the "Show Ojb-C Only" filter set in Instruments. While this makes the > report more compact, it also hides some important details. When I disable > that, and "Invert Call Tree" setting, I see this: > > 2331 Thread 0x8eff : -[NSThread main] :0 > 2331_pthread_body > 2331 __NSThread__main__ > 2331-[NSThread main] > 2331 +[NSURLConnection(NSURLConnectionReallyInternal) > _resourceLoadLoop:] > 2331CFRunLoopRunInMode > 2331 CFRunLoopRunSpecific > 2331mach_msg_trap > > Two things of interest to note here: > > * You have the same sample count for all "frames", meaning that every sample > found the same backtrace. This is, btw., true for all threads in this report. > > * The "mach_msg_trap" is symbol that you should learn to recognize as > indicating that this thread is "parked", waiting for more work. If you look > at the other treads, you'll find that they're all parked in the same, or > similar, places. > > So, to summarize: Your application is completely idle in this report. You > didn't expect any activity, and there isn't any. > > j o a r > > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Continuous zoom in MKMapView
On Jul 5, 2010, at 2:47 AM, Miguel Arroz wrote: > Hello, > > I'm trying to control a map view programmatically, and I need to zoom in and > out with high accuracy (like when the user pinches it for zomming, the map > may display an arbitrary level of zoom when the user stops touching the view). > > However, when I do it programmatically, with setRegion:animated: or > setVisibleMapRect:animated:, the behavior is different than what I expect. It > appears that the map view has some predefined zoom levels, and it will > massage the region or rect I pass to those calls and adjust it to the nearest > approximation for those predefined zoom levels. This prevents me from setting > an arbitrary zoom level, or making a continuous zooming effect. > > Is there any way to tell the map view I want that specific region or rect, > and not the approximation? I'm not sure about MKMapView but if it behaves the same way UIScrollView does... are those rects proportional to the view bounds? I'm asking this because UIScrollView does an AspectFit to the rect you pass in when zooming, so to have complete control of where you want the final bounds to be, you need to pass a proportional rect. > > Miguel Arroz > > ___ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/pfca%40mega.ist.utl.pt > > This email sent to p...@mega.ist.utl.pt ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Data conflict detection
Hello, I'm trying to get my head around how Core Data handles optimistic locking failures but still haven't figured this out. This discussion is purely conceptual, I have no sample code to back my assumptions, its purpose is to clarify what should happen in various scenarios. Core Data uses snapshots to detect conflicts. When saving a dirty object, if the values on the snapshot for that object are different than those on the persistent store you have a conflict. However, the mechanism that makes this work is not explained. Leading me to the following questions. Problem 1: Detecting conflicts on stores other than SQL For the SQLStore it's is easy to imagine that an update to an object as a "WHERE" clause referencing the previous values from the snapshot, similarly to what EOF does. It doesn't really matter exactly how Core Data does this but one must create a mental model. (From the little SQLDebug statements I've seen, I'm guessing that Core Data uses the private "Z_OPT" field to keep a version of the tuple on the database and uses this for optimistic locking… this is pure guessing). But how does this work for the XMLStore? Or custom stores using the NSAtomicStore? Is the file re-read to see if it is changed? (Note that there is no Z_OPT here, so there must be another way) Since Core Data isn't supposed to be used in cases where the underlying file changes beneath it (ie, multiple applications accessing the same file) this isn't really a problem. If that Core Data application is the only one reading and writing to that file this scenario should not happen. Leading me to believe conflict detection is made higher up on the stack. Jump to the next problem. Problem 2: Concurrency This problem has mainly to do with snapshots, where they are stored and with what they are compared with when saving. Imagine this scenario: You have two threads (T1 and T2) each with their own managed object context (moc1 and moc2) which use the same persistent store coordinator. 1 - T1 reads ObjectX 2 - T2 reads ObjectX 3 - T1 makes some changes to ObjectX 4 - T2 makes some other changes to ObjectX and saves < at this point the snapshot should be updated > 5 - T1 tries to save I'm expecting a conflict after point 5. But what does Core Data use to know this? If the snapshot is updated with the new value at step 4, the snapshot values are equal to what is on the persistent store. Show does "Core Data" know there is a conflict? And who owns the snapshots? Is it NSPersistentStore, NSPersistentStoreCoordinator or the NSManagedObjectContext? I'm hoping I've been clear and this will lead to a healthy discussion on the intricacies of conflict detection. Best regards, Paulo Andrade ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data conflict detection
Hello,
I did a small test to verify that indeed an error occurred.
Here is the relevant part of the code:
// Create our two peer editing contexts
NSManagedObjectContext *moc1 = newManagedObjectContext();
NSManagedObjectContext *moc2 = newManagedObjectContext();
// Instantiate managed object on moc1
NSManagedObject *moc1Sequence = [moc1 objectWithID:objID];
NSNumber *moc1Value = [moc1Sequence valueForKey:COUNTER_ATTRIBUTE];
NSLog(@"Moc1 read sequence with value %@", moc1Value);
// Instantiate managed object on moc1
NSManagedObject *moc2Sequence = [moc2 objectWithID:objID];
NSNumber *moc2Value = [moc2Sequence valueForKey:COUNTER_ATTRIBUTE];
NSLog(@"Moc2 read sequence with value %@", moc2Value);
// Moc1 makes changes
[moc1Sequence setValue:[NSNumber numberWithInt:[moc1Value intValue] + 1]
forKey:COUNTER_ATTRIBUTE];
NSLog(@"Moc1 incremented sequence to value %@", [moc1Sequence
valueForKey:COUNTER_ATTRIBUTE]);
// Moc2 makes changes
[moc2Sequence setValue:[NSNumber numberWithInt:[moc2Value intValue] + 1]
forKey:COUNTER_ATTRIBUTE];
NSLog(@"Moc2 incremented sequence to value %@", [moc2Sequence
valueForKey:COUNTER_ATTRIBUTE]);
// Moc1 save
if (![moc1 save:&error]) {
NSLog(@"Error while saving Moc1\n%@",
([error localizedDescription] != nil) ? [error
localizedDescription] : @"Unknown Error");
exit(1);
} else {
NSLog(@"Moc1 saved");
}
// Moc2 save
if (![moc2 save:&error]) {
NSLog(@"Error while saving Moc2\n%@",
([error localizedDescription] != nil) ? [error
localizedDescription] : @"Unknown Error");
exit(1);
} else {
NSLog(@"Moc2 saved");
}
Running this for either the SQL store or the XML store outputs:
2010-07-25 17:42:35.643 CoreData Test[1103:a0f] Moc1 read sequence with value 0
2010-07-25 17:42:35.646 CoreData Test[1103:a0f] Moc2 read sequence with value 0
2010-07-25 17:42:35.647 CoreData Test[1103:a0f] Moc1 incremented sequence to
value 1
2010-07-25 17:42:35.648 CoreData Test[1103:a0f] Moc2 incremented sequence to
value 1
2010-07-25 17:42:35.653 CoreData Test[1103:a0f] Moc1 saved
2010-07-25 17:42:35.657 CoreData Test[1103:a0f] Error while saving Moc2
Could not merge changes.
Which is what was expected (and confirms that this indeed does not work like
EOF). Than when I was reading what was in the error's user info I found this in
the documentation for NSManagedObjectContext:
Each conflict record in the @"conflictList" array in the userInfo dictionary
for an error from theNSErrorMergePolicy is a dictionary containing some of the
keys described in the following table. Of the cachedRow, databaseRow, and
snapshot keys, only two will be present depending on whether the conflict is
between the managed object context and the persistent store coordinator
(snapshot and cachedRow) or between the persistent store coordinator and the
persistent store (cachedRow and databaseRow).
So it seems the snapshots are held at the managed object context level, and a
cachedRow is held at the persistent store level. These two allow for conflict
detection on every persistent store type (being it SQL or not). I'm guessing
the databaseRow key will only ever be filled for the SQL store.
Printing the value of the conflictList on the example above:
conflictList: (
{
cachedRow = {
counter = 1;
};
newVersion = 2;
object = " (entity: Sequence; id:
0x2000228c0 ;
data: {\ncounter = 1;\n})";
oldVersion = 1;
snapshot = {
counter = 0;
};
}
)
Feels like I'm guessing closer at understanding the Core Data stack :). I don't
like it when it feels like magic.
Regards,
Paulo Andrade
On Jul 21, 2010, at 4:41 PM, Miguel Arroz wrote:
> Hi!
>
> On 2010/07/19, at 14:04, Paulo Andrade wrote:
>
>> You have two threads (T1 and T2) each with their own managed object context
>> (moc1 and moc2) which use the same persistent store coordinator.
>>
>> 1 - T1 reads ObjectX
>>
>> 2 - T2 reads ObjectX
>> 3 - T1 makes some changes to ObjectX
>> 4 - T2 makes some other changes to ObjectX and saves
>> < at this point the snapshot should be updated >
>> 5 - T1 tries to save
>>
>>
>> I'm expecting a conflict after point 5. But what does Core Data use to know
>> this? If the snapshot is updated with the new value at step 4, the snapshot
>> values are equal to what is on the persistent store.
>
> That is an interesting question. I've always been "curious" about this issue
> in Core Data's bi
Recovering from a merge conflict
Hello,
I have an application using Core Data that has to import/update some data to/in
the database.
It imports in batches and it conflict may happen. Some object being updated in
a batch might also be updated in another context.
This is fine and I'm aware that this will happen. What I want to do is start
this batch from the beginning.
The problem is that I cannot make NSManagedObjectContext forget about the merge
error!
The code is something like this
===
// at this point all [moc hasChanges] is NO
int tries = 10;
while ( tries-- ) {
// compute this batch
[moc save:&error];
if (error != nil && [error code] == NSManagedObjectMergeError) {
[moc rollback];
NSLog(@"Got optimistic locking error %...@\n. Retrying...", [error
description]);
continue;
} else {
break;
}
}
==
It seems rollback isn't enough, iterating over [moc updatedObjects] and calling
refreshChanges:mergeObject: also doesn't work.
1- So how can I mark a conflict as resolved?
2- Why is the NSMergeConflict object private? Is the only way to find which
object caused the error is to print that object and look at that message?
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Recovering from a merge conflict
On Dec 21, 2010, at 3:08 PM, Fritz Anderson wrote:
> On 21 Dec 2010, at 8:36 AM, Paulo Andrade wrote:
>
>> int tries = 10;
>> while ( tries-- ) {
>> // compute this batch
>>
>> [moc save:&error];
>> if (error != nil && [error code] == NSManagedObjectMergeError) {
>
> This may not be your main problem, but you should never inspect a returned
> error object unless the method that returned it reports a failure:
>
> if (! [moc save: &error] && [error code] == NSManagedObjectMergeError) {
> ...
>
> Such methods are free to set the error object at their start, in case they
> fail, but the error is correct only if the method does fail.
>
> — F
>
Thanks for noticing that, actually did not know about that. Is that written
anywhere on Apple's docs?
It's not that consistent either, take executeFetchRequest:error: for example.
But yes, I understand that I should first use the method error reporting if it
exists before delving in the NSError object.
Anyway, back to the original question..
anyone?___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
