Compare Revisions

Optimizing startup performance

Change Revisions

Revision 380479:

Revision 380479 by Sheppy on

Revision 380481:

Revision 380481 by Sheppy on

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

Revision 380479
Revision 380481
nn54    <h3>
55      Porting issues
56    </h3>
n55      Once the initial loading is done and the app's main code stn58      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>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>eaded,especially if it's a port. The most important thing to do t
> to try to help with the main code's startup process is to refact>o try to help with the main code's startup process is to refactor
>or the code into small pieces that can be done in chunks interspe> the code into small pieces that can be done in chunks interspers
>rsed across multiple calls to your app's main loop, so that the m>ed across multiple calls to your app's main loop, so that the mai
>ain thread gets to handle input and the like.>n thread gets to handle input and the like.
tt66    <h3>
67      How asynchronous should I get?
68    </h3>
69    <p>
70      It's worth keeping in mind that most browsers typically sta
 >rt complaining that your script is blocking the main thread for t
 >oo long at around 10 seconds or so. Ideally, you won't block anyw
 >here near that long, but as long as you keep it below that, you s
 >hould be okay. Keep in mind, though, that if someone has an older
 >, slower computer than yours, they may experience longer delays t
 >han you do!
71    </p>
72    <h2>
73      Other suggestions
74    </h2>
75    <p>
76      There are other things beyond going asynchronous, which can
 > help you improve your app's startup time. Here are a few of them
 >:
77    </p>
78    <dl>
79      <dt>
80        Download time
81      </dt>
82      <dd>
83        Keep in mind how long it will take the user to download y
 >our game's data. If your game is really big, really popular, or h
 >as to re-download content frequently, you should try to have as f
 >ast a hosting server as possible. You should also consider gzippi
 >ng your data to make it as small as you can.
84      </dd>
85      <dt>
86        GPU factors
87      </dt>
88      <dd>
89        Compiling shaders and uploading textures to the GPU can t
 >ake time, especially for really intricate games. While this happe
 >ns with native (non-Web) games too, it can still be pretty annoyi
 >ng. Avoid doing this without keeping the user apprised that the g
 >ame is in fact still starting up.
90      </dd>
91      <dt>
92        Data size
93      </dt>
94      <dd>
95        Do your best to optimize the size of your game data; smal
 >ler level files will download and be processed faster than larger
 > ones.
96      </dd>
97      <dt>
98        Subjective factors
99      </dt>
100      <dd>
101        Anything you can do to help keep the user engaged during 
 >the startup process will help make the time seem to go by faster.
 > For games, consider having background music playing or a nice sp
 >lash screen displayed. In between calculations, update your progr
 >ess indicator, make changes to the display, or anything else you 
 >might be able to do to help the user feel like your app is doing 
 >something instead of sitting there quietly.
102      </dd>
103    </dl>
104    <h2>
105      See also
106    </h2>
107    <ul>
108      <li>
109        <a href="/en-US/docs/Apps" title="/en-US/docs/Apps">Apps<
 >/a>
110      </li>
111      <li>
112        <a href="/en-US/docs/Games" title="/en-US/docs/Games">Gam
 >es</a>
113      </li>
114    </ul>

Back to History