Collecting performance metrics using renderTemplate hook and User Timing API

For my pet project, on iPhone, I’m seeing up to about 40-50% performance increase with HTMLBars (Ember1.10) vs Handlebars 1.3 (Ember 1.8) See: https://twitter.com/pixelhandler/status/564476770595143683

Ember 1.10 (HTMLBars) http://pixelhandler.com/api/metrics/durations?name=index_view&emberVersion=1.10&userAgent=iPhone http://pixelhandler.com/api/metrics/durations?name=application_view&emberVersion=1.10&userAgent=iPhone

Ember 1.8 (Handlebars) http://pixelhandler.com/api/metrics/durations?name=index_view&emberVersion=1.8&userAgent=iPhone http://pixelhandler.com/api/metrics/durations?name=application_view&emberVersion=1.8&userAgent=iPhone

And on a userAgent search for Mobile about 15% increase http://pixelhandler.com/api/metrics/durations?name=index_view&emberVersion=1.10&userAgent=Mobile http://pixelhandler.com/api/metrics/durations?name=index_view&emberVersion=1.8&userAgent=Mobile

Here is the API I made to search the metrics: https://github.com/pixelhandler/blog/tree/master/server#metrics-api-endpoints I ran Ember 1.8 for about a day then when 1.10 shipped ran that only since last night, but average index_view template load times are looking better.

Last week I added User Timing measurements in the renderTemplate hook like so https://github.com/pixelhandler/blog/commit/167be4c321a823c9ad8a9ff6569fed7672dd0cd8 I’m made some tweeks on the analytics data collection since then.

I’m curious how are you measuring performance in your Ember apps ?

See Post: Measuring Performance with User Timing API, in an Ember Application

1 Like

Did you run any metrics on memory overhead differences between the two?

No, I measured general analytics plus render timings (with user timings) window.performance

I’ll be upgrading our cordova iOS app this week, I’ll try to pull out some CPU/Memory usage differences. I’m really hoping this reduced Ember’s footprint, which would help Android performance on poor devices a lot.

@jthoburn - The total size is slightly less (102kb min+gz), but not massively less.

@rwjblue I meant runtime footprint :wink:

A lot of Android devices have <= 250MB RAM and powerless CPUs. We ran into a lot of problems building an Android app that would work well on non-flagship phones. Our Ember runtime often hits 50-100MB in Chrome and can spike higher. I’ve been working pretty hard to reduce this (successfully), but am hoping HTMLbars will give that work a good boost. I was able to get a few metrics off the HTMLbars beta that suggested there would be improvement, but too many addons (including some of my own) weren’t ready for HTMLbars at the time to get a true read.

@jthoburn Just saw this link via ember weekly newsletter https://github.com/stefanpenner/ember-browser-stats

@pixelhandler That’s awesome! Missed that in the newsletter.

Not sure if anyone else is seeing this but I suspect there may be a memory leak in Ember 1.10. I haven’t had time to dig into any profiles to see what exactly is going on. Initially, 1.10 helps our our memory usage ~30%, but leaving our app running, its memory usage now perpetually climbs ~.25-1 MB / minute.

Curious if anyone else has observed this.