hello,
i found something peculiar: the very first http/https network load in the app even when done on a background queue affects the main thread significantly. have a look at the screen recording of the app:
http shorturl.at/nxAE4
and how non linear the scrolling performance is:
http shorturl.at/uADY2
there i scroll a list of simple items and when it hit item 30 it loads it on a background queue. result (in this case error) is delivered on another background queue and ignored. the second load of this or a different URL doesn't cause such delay.
what exactly is system doing on the main thread here and can it not do it elsewhere?
what is the best way to figure what extra code is executed on main thread? i tried instruments with various tools in it but can't make heads or tails of it to figure out what exactly is going on here.
the sample code that used for url loading:
i found something peculiar: the very first http/https network load in the app even when done on a background queue affects the main thread significantly. have a look at the screen recording of the app:
http shorturl.at/nxAE4
and how non linear the scrolling performance is:
http shorturl.at/uADY2
there i scroll a list of simple items and when it hit item 30 it loads it on a background queue. result (in this case error) is delivered on another background queue and ignored. the second load of this or a different URL doesn't cause such delay.
what exactly is system doing on the main thread here and can it not do it elsewhere?
what is the best way to figure what extra code is executed on main thread? i tried instruments with various tools in it but can't make heads or tails of it to figure out what exactly is going on here.
the sample code that used for url loading:
Code Block let someQueue = DispatchQueue(label: "someQueue") let otherQueue = DispatchQueue(label: "otherQueue") var someOpQueue: OperationQueue = { let q = OperationQueue() q.underlyingQueue = someQueue q.name = "someOpQueue" return q }() var session = URLSession(configuration: .default, delegate: nil, delegateQueue: someOpQueue) func loadUrl(_ url: URL) { otherQueue.async { let task = session.dataTask(with: url) { d, r, e in /* ignore */ } task.resume() } }
One of the first things you could do here is look at the handoff between your background queue and the main to see if this is causing a bottleneck. If this is not the cause, then look at how your app actually reads the data to reload the tableview. I suspect something in either one of these scenarios is causing the issue.
As for how this can be done, you can try and investigate this with Time Profiler in Intruments:
Using Time Profiler in Instruments:
<https://developer.apple.com/videos/play/wwdc2016/418/>
When you do this, look for points on where you have significant jumps in CPU and dig into your call trees from there. These jumps in CPU will be denoted by spikes of on the bar graph.
When you use the Time Profiler, at the top left under your target device you may see a filter for "ATTRIBUTE: target" and "ANY: *". Try changing the ANY filter to THREAD. This should give you a look at the threads running during your profile capture and allow you to see the activity on the main thread. These threads will have a complete stack trace available for your to view. This can be helpful when debugging situations like this.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
As for how this can be done, you can try and investigate this with Time Profiler in Intruments:
Using Time Profiler in Instruments:
<https://developer.apple.com/videos/play/wwdc2016/418/>
When you do this, look for points on where you have significant jumps in CPU and dig into your call trees from there. These jumps in CPU will be denoted by spikes of on the bar graph.
When you use the Time Profiler, at the top left under your target device you may see a filter for "ATTRIBUTE: target" and "ANY: *". Try changing the ANY filter to THREAD. This should give you a look at the threads running during your profile capture and allow you to see the activity on the main thread. These threads will have a complete stack trace available for your to view. This can be helpful when debugging situations like this.
Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com