mozilla

Compare Revisions

Optimizing startup performance

Change Revisions

Revision 380473:

Revision 380473 by Sheppy on

Revision 380479:

Revision 380479 by Sheppy on

Title:
Optimizing startup performance
Optimizing startup performance
Slug:
Apps/Developing/Optimizing_startup_performance
Apps/Developing/Optimizing_startup_performance
Tags:
"Games", "Apps", "Performance"
"Apps", "Games", "Performance"
Content:

Revision 380473
Revision 380479
n8      An often overlooked aspect of app software development—evenn8      An often overlooked aspect of app software development—even
> among those focusing on performance optimization—is startup perf> among those focusing on performance optimization—is startup perf
>ormance. How long does your app take to start up? Does it seem to>ormance. How long does your app take to start up? Does it seem to
> lock up the device or the user's browser while the app loads? Th> lock up the device or the user's browser while the app loads? Th
>at makes users worry that your app is crashed, or that something >at makes users worry that your app is crashed, or that something 
>else is wrong. It's always a good idea to take the time to ensure>else is wrong. It's always a good idea to take the time to ensure
> that your app starts up nicely. This article offers tips and sug> that your app starts up nicely. This article offers tips and sug
>gestions to help you achieve that goal.>gestions to help you achieve that goal, both when writing a new a
 >pp and when porting an app from another platform to the Web.
n10    <h2>n10    <h2 id="Starting_up_nicely">
nn22    <h2>
23      Where there's a will...
24    </h2>
t23      &nbsp;t26      If you're starting your project from scratch, it's usually 
 >pretty easy to just write everything the "right way," making appr
 >opriate bits of the code asynchronous. All pure startup calculati
 >ons should be performed in background threads, while you keep the
 > run-time of main thread events as short as possible. Include a p
 >rogress indicator so the user knows what's going on and how long 
 >they'll be waiting. In theory, anyway, it should be pretty easy t
 >o design your new app to start up nicely.
27    </p>
28    <p>
29      On the other hand, however, it can get tricky when you're p
 >orting an existing app to the Web. A desktop application doesn't 
 >need to be written in an asynchronous fashion because usually the
 > operating system handles that for you, or the app is the only th
 >ing that matters which is currently running, depending on the ope
 >rating environment. The source application might have a main loop
 > that can easily be made to operate asynchronously (by running ea
 >ch main loop iteration separately), startup is often just a conti
 >nuous, monolithic procedure that might periodically update a prog
 >ress meter.
30    </p>
31    <p>
32      While you can use <a href="/en-US/docs/DOM/Using_web_worker
 >s" title="/en-US/docs/DOM/Using_web_workers">Web workers</a> to r
 >un even very large, long-duration chunks of <a href="/en-US/docs/
 >JavaScript" title="/en-US/docs/JavaScript">JavaScript</a> code as
 >ynchronously, there's a huge caveat that: workers don't have acce
 >ss to <a href="/en-US/docs/WebGL" title="/en-US/docs/WebGL">WebGL
 ></a> or audio, and they can't send synchronous messages to the ma
 >in thread, so you can't even proxy those APIs to the main thread.
 > This all means that unless you can easily pull out the "pure cal
 >culation" chunks of your startup process into workers, you'll win
 >d up having to run most or all of your startup code on the main t
 >hread.
33    </p>
34    <p>
35      However, even code like that can be made asynchronous, with
 > a little work.
36    </p>
37    <h2>
38      Getting asynchronous
39    </h2>
40    <p>
41      Here are some suggestions for how to build your startup pro
 >cess to be as asynchronous as possible (whether it's a new app or
 > a port):
42    </p>
43    <ul>
44      <li>If you need to decode asset files (for example, decodin
 >g JPEG files and turning them into raw texture data for later use
 > by WebGL), that's great to do in workers.
45      </li>
46      <li>When dealing with data supported by the browser (for ex
 >ample, decoding image data), use the decoders built into the brow
 >ser or device rather than rolling your own or using one from the 
 >original codebase. The provided one is almost certainly significa
 >ntly faster, and will reduce your app size to boot. In addition, 
 >the browser may automatically parallelize these decoders.
47      </li>
48      <li>Any data processing that can be done in parallel should
 > be. Don't do one chunk of data after another; do them all at onc
 >e when possible!
49      </li>
50    </ul>
51    <p>
52      The more stuff you can do asynchronously, the better advant
 >age your app can take of multicore processors.
53    </p>
54    <p>
55      Once the initial loading is done and the app's main code st
 >arts to run, it's possible your app may necessarily be single-thr
 >eaded (especially if it's a port). The most important thing to do
 > to try to help with the main code's startup process is to refact
 >or the code into small pieces that can be done in chunks interspe
 >rsed across multiple calls to your app's main loop, so that the m
 >ain thread gets to handle input and the like.
56    </p>
57    <p>
58      Emscripten provides an API to help with this refactoring; f
 >or example, you can use <code>emscripten_push_main_loop_blocker()
 ></code> to establish a function to be executed before the main th
 >read is allowed to continue. By establishing a queue of functions
 > to be called in sequence, you can more easily manage running bit
 >s of code without blocking the main thread.
59    </p>
60    <p>
61      That leaves, though, the problem of having to refactor your
 > existing code to actually work that way. That can take some time
 >.

Back to History