Moving to mobile-l. See thread below. Additionally, Brion Vibber noted the following:
<snip> Nice!
A couple quick notes:
* Face detection can be moved to a background thread to keep it from blocking the UI, pretty easily I think
* It looks like HTML parsing of the article is pretty expensive, especially on a big one like the Obama page. Might want to reconsider the idea of progressively feeding parts of the article in for parsing, whether that's dribs and drabs sent over the bridge or directly via the network and using incremental rendering during the download. (Currently I think the whole page is loaded in as a single string via the loadHTMLString:baseURL: method on the web view after it's been downloaded and saved to storage, and that doesn't leave much time for incremental rendering.) This should also space out the CPU cost of parsing in between download and rendering, and should get "first pixels on screen" much faster.
* Sounds like the image caching can be improved a lot; you have a great todo list already :D
</snip>
---------- Forwarded message ---------- From: Brian Gerstle bgerstle@wikimedia.org Date: Wed, Feb 25, 2015 at 3:03 PM Subject: Re: [ios] Instruments trace To: Dan Garry dgarry@wikimedia.org Cc: mobile-tech mobile-tech@wikimedia.org
On Wednesday, February 25, 2015, Dan Garry dgarry@wikimedia.org wrote:
On 25 February 2015 at 14:14, Brian Gerstle bgerstle@wikimedia.org wrote:
We're already near max CPU usage while loading an article (time profiler clocks us at around 80-90% peaking well over 100%—our app makes the CPU faster!)
Our app is so unperformant that it breaks the basic principles of mathematics. Nice.
I mean this in the nicest way: I read that in Jon Oliver's voice
We quickly found a number of "big (CPU) spenders" that we should be able to optimize in parallel by splitting the work amongst the devs. I've started an etherpad where we can scratch notes http://etherpad.wikimedia.org/p/instruments_observations on the attached trace, and link to phab tickets as we identify issues.
Good stuff.
I'll go ahead and create notes & corresponding tickets for the things
Monte and I discovered. I highly encourage other devs to have a look when they're done with their current work items to see if we can gain any more insight from this trace.
Great. The more material we have for our ticket busting meeting tomorrow, the better!
Oh don't worry, there will be plenty.
If we want, I can conduct a spike to convert these steps into a rudimentary automation script. *It should take less than a day* and will give us a way to *accurately reproduce the measurements on all our machines* and be able to *relatively compare differences in performance caused by our patches*.
We're not in a position to be able to prioritise this yet. Let's focus our energy on getting the immediate problem fixed first.
I agree, we can try to reproduce our results manually at first. If that proves to be unreliable, we will let you know and draft a plan accordingly.
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation