Now, the second of our 3 pillars is going to be
compute performance. And, to get a sense of how your application is
actually spending it's time during a given frame, you really want
to check out the timeline tab inside of Chrome developer tools. How
this works, is that you actually load the timeline, hit this
beautiful record button down here on the bottom, and then watch magic
unfold. So, let's take look at how this plays out with
Biolad Disaster. If I start the game, it goes up very simple.
Now, when I hit the record button down here on the bottom, you
can actually see that it's logging all of the event information that's occurring
while this game is happening. Now, I'm not doing anything, I want to point
that out, yet events are actually being fired. So, let's take a look at
what's actually going on under the hood here. So, if I size this
up, I can actually see the number of events inside of my window
and drill down into what's going on. So, I've an animation frame here.
And if I expand that, you can see that there's actually a request animation
frame that has occurred at that point. Now,
you'll notice down here on the bottom that there's
actually different type of check boxes to filter
out what events you're looking at. And each one
has a respective color. For example, loading is
blue, scripting is gold, rendering is purple and painting
is green. So, if I toggle painting you can
see that those events actually disappear from the timeline.
Now, I did another quick little capture while you weren't looking,
I saw you going to get peanuts from the bag. Now, if
I slide my visibility window to another part of the timeline,
you can see that there's actually a little block here that seems
to be wider than all the other blocks around it, what
this implies is that there's some scripting occurring between our windows here
that is taking longer than the other frames. Now, below us, we
actually have a list of events that occurred, plus as you remember
these little triangles that allows us to drill down into the
event. On here in the side, you can see that we
have the same animation Frame Fire that we saw earlier, but
the new one that we see showing up, is a GC Event,
where 1.4 megabytes of data was actually collected. Hovering over it
brings a popup dialogue that shows you that this actually took
2.7 milliseconds, out of our frame budget to actually do a
garbage collection event. That's why you can see that this block here,
is actually larger then the block next to it, because
we have an extra 2.7 miliseconds that went to do
a garbage collection event. We can actually see this mirrored,
by clicking on the memory option for the timeline. Now, what
this's actually going to show us is a linear graph of
where allocations are actually occuring, and lo and behold, you can
see, between our 2 divets here, when that GC event
occurs, the amount of memory allocated in our application drops down,
thus showing the garbage collection freed memory. Now, I want to show
you what this looks like live, because it's really interesting to watch.
How an application, actually allocates its memory. So, you can see
that over time, this application, when I'm doing nothing on the screen,
is actually allocating about 1 megabyte every second or so. And
then you can see the garbage collector actually kicks in, and frees
a lot of that data. This type of sawtooth pattern that
you're seeing along the timeline here, is very common in different web
applications, that do a lot of dynamic allocation of objects. Now, there's an
article out there that I've written on HTML 5 Rocks, that details different ways
to address this type of sawtooth pattern,
using object pools. But, we're not going to
go into that right now. Let's stay focused on what's in front of us.
El segundo de nuestros 3 pilares será
el funcionamiento de cálculos. Y para darles una idea de cómo su aplicación
está realmente usando el tiempo durante un fotograma, lo que realmente quieres
es revisar la pestaña de cronología dentro de las herramientas del programador Chrome.
Cómo funciona, es cargando en la cronología, pulsa este precioso
botón de grabación aquí abajo y mira el mágico despliegue.
Vamos a echar un vistazo a ver cómo te desenvuelves con
Bioland Disaster. Si empiezo el juego, aumenta muy fácilmente.
Cuando presiono el botón de grabación aquí abajo,
puedes observar que está registrando toda la información de los eventos que se están llevando a cabo
mientras el juego está en funcionamiento. Ahora no estoy haciendo nada, quiero destacar
que sin embargo, los eventos están lanzándose en realidad.
Así que vamos a ver que está pasando realmente en su rendimiento.
Si aumento esto, puedo ver el número de eventos dentro de mi ventana
y profundizar sobre qué esta pasando. Esto es un cuadro de animación.
Si expando esto, puedes ver que hay una petición de encuadre de animación
que se ha producido en este punto.
Podrás observar que en la parte inferior aquí
hay diferentes tipos de casillas para filtrar
qué eventos estás observando.
Cada uno tiene su respectivo color. Por ejemplo, cargar
es azul, encriptar dorado, la representación morada y pintar es verde.
Si altero la pintura
puedes ver que estos eventos desaparecen de la cronología.
He hecho una pequeña captura mientras no estabas mirando,
te he visto ir a por cacahuetes de la bolsa.
Si deslizo la visibilidad de mi ventana a otra parte de la cronología,
puedes observar que hay un pequeño bloque aquí que parece ser
más ancho que los demás bloques que lo rodean,
lo que esto implica es que hay una especie de encriptamiento entre nuestras ventanas aquí
que está llevando más tiempo que a los demás cuadros. Debajo de nosotros
tenemos una lista de eventos que han ocurrido, además como recordarán
estos pequeños triángulos que nos permiten profundizar en el evento.
Aquí al lado, puedes ver que
tenemos la misma animación "Frame Fire" que hemos visto antes, pero
la nueva que se nos muestra es un "GC Event",
donde se recolectan 1,4 megabytes de datos.
Filtrándose se muestra un diálogo desplegable que lleva
2,7 milisegundos, fuera de nuestra capacidad de cuadro para hacer
un evento de recogida de basura. Esa es la razón por la que puede ver que este bloque aquí
es más grande que el bloque al lado de este, porque
tenemos 2,7 milisegundos extra que hacen
un evento de recogido de basura. Podemos verlo reflejado,
clicando en la opción de memoria sobre la cronología.
Lo que nos va a mostrar ahora esta es un gráfico linear
donde se están llevando a cabo las asignaciones, y para su sorpresa,
puedes ver entre nuestros 2 divets aquí, que cuando ocurre este evento GC
la cantidad de memoria asignada en nuestra aplicación cae,
mostrándonos que la recolección de basura libera memoria.
Ahora quiero mostraros como funciona en directo. Es muy interesante de ver.
Cómo una aplicación, realmente asigna su memoria.
Puedes ver con el tiempo, que cuando no hago nada en la pantalla,
están asignados alrededor de 1 megabyte por segundo más o menos.
Y después puedes ver que el recolector de basura decrece y libera
muchos datos. Este tipo de patrón de dientes de sierra
que estás viendo a lo largo de la cronología aquí, es muy común
en diferentes aplicaciones web, esto hace que la asignación de objetos sea más dinámica.
Hay un artículo que escribí en HTML 5 Rocks que detalla las diferentes formas
para abordar este tipo de patrón de dientes de sierra, utilizando
agrupaciones de objetos. Pero no vamos a tratar eso ahora.
Vamos a centrarnos en lo que tenemos enfrente.
3つの柱の2番目は計算性能です
アプリがフレームで実際に どのように時間を費やしているか
把握するためにChromeデベロッパーツールの
タイムラインタブをチェックします
タイムラインをロードして
このRecordボタンを押します さあ魔法をご覧ください
Biolad Disasterのプレイ方法を説明します
ゲームはとてもシンプルです
このRecordボタンを押すと
ゲーム中のすべてのイベント情報が記録されます
特に何もしていませんが
イベントが本当に起こっていることを強調したいのです
実際に起こっているものを見てみましょう
サイズを変更すればいくつもイベントが表示できます
これはアニメーションフレームです
展開すればその時点の リクエストアニメーションフレームが
実際にあることが分かります
下の段には検証するイベントを
フィルタするチェックボックスがあります
ボタンは色分けされています
Loadingは青でScriptingはゴールド
Renderingは紫でPaintingは緑です
Paintingのチェックを外すと
そのイベントがタイムラインから消えます
では別の面をざっと見てみましょう
ちょっと飽きてきましたか?
タイムラインの別の部分にウィンドウをスライドすると
周囲の他のすべてのブロックより
広く見えるブロックがあることが分かります
これはスクリプト作業がウィンドウ間で
他のフレームより長くかかっていることを意味します
この下には実際に生じたイベントがリストされています
この小さな三角形で詳細が見られます
こらちには以前に見たのと同じ
Animation Frame Firedがあります
さらに新しくGC Eventが追加されています
1.4メガバイトのデータが実際に収集されています
ポップアップダイアログが表示され
ガベージコレクションイベントが2.7ミリ秒も
かかったことを示します そのためこのブロックは
他のブロックよりも大きいのです
ガベージコレクションイベントのために余分な2.7ミリ秒が
かかっているからです 実際にこれが反映されたことを
タイムラインのメモリオプションで確認できます
これはアロケーションがどこで生じているかを示す 線形のグラフです
さらにご覧ください
ガベージコレクションイベントが生じる場合
この2者の間にアプリケーションで割り当てられた メモリの量がこのように落ちています
メモリが解放されたことを示しているのです
ではリアルタイムで見てみましょう
アプリがどのようにメモリを割り当てるか見えます
このように何もしていなくても時間と共に
アプリが毎秒約1メガバイト程度を 割り当てています
ガベージコレクタがデータの多くを 解放していることが分かります
タイムラインに沿って
オブジェクトの動的割当てを多用するWebアプリでは
このようなギザギザのパターンが現れます
私がHTML5 Rocksで書いた記事の中で オブジェクトプールを使って
ギザギザのパターンに取り組む様々な方法を 説明しています
それには今回は触れません 次に進みましょう
O segundo de nossos 3 pilares será o desempenho computacional.
E para ter uma noção de como seu aplicativo
realmente emprega seu tempo durante um determinado intervalo
você terá de checar a aba Timeline no Chrome DevTools.
Isso opera carregando a linha do tempo.
Clique neste lindo botão de gravar aqui embaixo, e então a mágica acontecerá.
Então, vamos dar uma olhada em como isso acontece no Biolab Disaster.
Se eu inicio o jogo, ele começa bem tranquilo.
Agora, se aperto o botão de gravar aqui embaixo
dá para ver que está registrando todas as informações dos eventos
que estão ocorrendo enquanto o jogo se desenrola.
Agora, não estou fazendo nada, quero destacar isso, e mesmo assim
os eventos estão sendo iniciados. Vamos então dar uma olhada
no que realmente está acontecendo debaixo do pano aqui.
Então, se aumento isso, posso ver o número de eventos dentro da minha janela
e detalhar o que está acontecendo. Tenho, então, um quadro de animação aqui.
Se o expando, é possível ver que existe realmente uma solicitação
de quadro de animação que ocorreu naquele momento.
Agora, você vai perceber que, aqui embaixo
existem diferentes tipos de caixas de seleção
para filtrar os eventos que você está vendo.
E cada uma tem uma cor respectiva. Por exemplo, carregar é azul,
criação de scripts é dourado, renderização é púrpura
e colorização é verde. Então, se mudo para colorização
é possível ver que esses eventos na verdade desaparecem da linha do tempo.
Agora, fiz outra rápida captura enquanto você não estava olhando.
Vi que você se distraiu para pegar amendoins do pacote.
Se eu arrastar minha janela de visibilidade para outra parte
da linha do tempo, posso ver que existe de fato um bloquinho aqui
que parece ser mais largo que todos os outros à sua volta
o que implica que existem scripts sendo criados aqui entre nossas janelas
que estão levando mais tempo que os outros quadros.
Aqui embaixo, temos uma lista de eventos que ocorreram.
E, além disso, como você se lembra,
esses pequenos triângulos que permitem ver dentro do evento.
Aqui do lado, podemos ver que
temos a mesma animação Frame Fire que vimos antes
mas a nova, que estamos mostrando,
é um evento GC, no qual 1,4 MB de dados foram coletados.
Passando o mouse por cima, uma caixa de diálogo mostra que
2.7 milissegundos de nossa reserva de quadros
foram usados para fazer um evento de coleta de lixo.
É por isso que você pode ver que este bloco
é na realidade maior que o bloco ao seu lado pois temos 2.7 milissegundos
adicionais que foram usados para um evento de coleta de lixo.
Podemos de fato ver isso espelhado
ao clicar na opção de memória para a linha do tempo.
Assim, o que vai de fato ser mostrado é um gráfico linear
dos locais em que as alocações estão realmente ocorrendo.
E, veja só, dá para ver entre nossas 2 fendas que, quando esse evento GC ocorre
a quantidade de memória alocada em nosso aplicativo despenca
mostrando assim a memória liberada na coleta do lixo.
Agora, quero mostrar como isso funciona ao vivo, pois é realmente interessante
de ver como um aplicativo realmente aloca sua memória.
Então, dá para ver que, ao longo do tempo, este aplicativo, quando não faço nada
na tela, está alocando cerca de 1 MB a cada segundo, mais ou menos.
E então dá para ver que o coletor de lixo entra em ação e libera muito desses dados.
Esse tipo de padrão serrilhado que vemos aqui
ao longo da linha do tempo, é muito comum em diversos aplicativos da web
que fazem muita alocação dinâmica de objetos.
Tem um artigo que escrevi sobre HTML5 Rocks
que detalha diferentes maneiras de lidar com esse tipo de padrão serrilhado
usando acervos de objetos. Mas não vamos entrar nisso agora.
Vamos manter o foco no que está diante de nós.