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 <[email protected]> Date: Wed, Feb 25, 2015 at 3:03 PM Subject: Re: [ios] Instruments trace To: Dan Garry <[email protected]> Cc: mobile-tech <[email protected]> On Wednesday, February 25, 2015, Dan Garry <[email protected]> wrote: > On 25 February 2015 at 14:14, Brian Gerstle <[email protected]> > 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
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
