Expressing similar
sentiments by Zynga CTO. Excerpts from the article: http://lists.w3.org/Archives/Public/public-web-perf/2012Sep/0016.html
Memory
While the navigation timing APIs help us
understand bottlenecks in our loading time performance,
we’d like you to help us analyze what’s
happening during runtime.
On mobile devices, the biggest performance
bottleneck for large scale, high fidelity apps and games turns out to be
memory consumption. As soon as you run out of physical memory, constant
swapping occurs and runtime performance of your web project dramatically
suffers.
As web developers, we currently have no way of
understanding how memory is consumed.
1. Javascript
* We don’t know how much memory a newly
created object or function allocates
* We can’t call the GC manually, and there is
no guarantee that calling “delete” will trigger the GC right away
2. Images
* We do not have access to the resource of an
image, just the DOM representation
* We can’t “unload” images reliably
* We don’t know when assets are uncompressed
* We don’t know when an uncompressed,
compressed or both representations of an image is kept in memory and for
how long
3. Static assets
* Static assets include:
* Non-interpreted JavaScript
* Stylesheets
* Uncompressed images
* We want to know how much total memory is
consumed by these static assets, as memory is usually shared across all of
the above
4. HW Acceleration
This is tricky as it is a platform specific
problem, but it doesn’t make it less important. A large number of browsers is
using a different render path for content they can hardware accelerate. Said
content is usually composited on the CPU first and then uploaded as a texture
to the GPU. At this point, it
becomes a “layer” and easy modifications
like opacity and moving the layer around to not trigger recreating the layer.
We need information on when layers are created, destroyed and recomposited. We
need this to understand performance characteristics, but we also need it to
control our total memory heap - an image wrapped in a div with a red
border that gets uploaded as a GPU layer consumes twice the amount of
uncompressed pixel memory.
We realize and appreciate that browser vendors
work hard on abstracting this issue and ideally agree that
acceleration should be automatic and no
concern to the web developer – but reality shows that we do not have that
luxury yet, as false layer management is hazardous.
Canvas
Almost all modern browsers hardware accelerate
Canvas nowadays and do so by trying to understand how long a certain
texture is needed on the GPU through a set of deterministic algorithms.
Unfortunately as developer, this often does more harm than good in an
environment when you have to be in full control of the situation. We want
to be able to understand when textures are kept in a buffer and when they’re
released again.
As a practical example: We have implemented a
scrolling worldmap as a proof-of-concept in canvas that
you could pan with the mouse/touch, and one
viewport was represented by one image drawn to the canvas. At first, we’d
always draw two adjacent pictures (so the user never see’s white background),
but if you let go of the mouse, we’d do a “bounce” deceleration of the movement
that shows the next logical image in the row. As soon as the logic detects
that it needs to draw a new image, texture swapping happens in the
background (especially visible on iOS) and you will notice a visible hitch
(50+ms). The unfortunate solution was to
always draw all three images at any given time, even when one of them was off
-screen.
5. Total available memory
We want to be able to query the total available
physical memory on the device running the browser
(or if it is capped for my web app, the capped
size).
Even though it doesn’t guarantee anything, it
allows us to better judge what we can do, and what we shouldn’t do.
6. Display refresh rates
It needs to be understood how much of a real
world problem this is, but it is relevant with any screen that isn’t set to 60
Hz or a multiple of it.
We’d like to query the display refresh rate and
the rAF interval in order to minimize jutter.
7. Garbage Collection
We want to be able to:
* Trigger garbage collection manually
* Understand the execution interval of GC (i.e
an event triggered on the window)
* Understand the time a GC took (in order to
optimize our framerate against it, could be reported through the same event)
* Disable GC and only trigger it manually
No comments:
Post a Comment