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(a)wikimedia.org>
Date: Wed, Feb 25, 2015 at 3:03 PM
Subject: Re: [ios] Instruments trace
To: Dan Garry <dgarry(a)wikimedia.org>
Cc: mobile-tech <mobile-tech(a)wikimedia.org>
On Wednesday, February 25, 2015, Dan Garry <dgarry(a)wikimedia.org> wrote:
On 25 February 2015 at 14:14, Brian Gerstle
<bgerstle(a)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
--
EN Wikipedia user page:
https://en.wikipedia.org/wiki/User:Brian.gerstle
IRC: bgerstle