Please note, this is a STATIC archive of website developer.mozilla.org from November 2016, cach3.com does not collect or store any user information, there is no "phishing" involved.

Performance

Este artigo necessita de uma revisão editorial. Como posso ajudar.

Esta tradução está incompleta. Ajude atraduzir este artigo.

Esta ferramenta é nova no Firefox 34.

As colunas no perfil de amostragem foram expandidos e renomeado no Firefox 35: esta página descreve os novos nomes das colunas.

A ferramenta de desempenho é o substituto para o perfil de amostragem JavaScript. Ele inclui uma versão atualizada do perfil de amostragem, mas acrescenta um cronograma taxa de quadros para ajudar a avaliar a capacidade de resposta. Temos a intenção de adicionar mais recursos em versões futuras.

Abrindo a ferramenta de desempenho

Você pode iniciar a ferramenta de desempenho, selecionando "Performance", no menu "Web Developer". Você encontrará o menu "Web Developer" sob o menu "Ferramentas" no Linux e OS X, e diretamente sob o menu "Firefox" no Windows. Alternativamente, Shift + F5 irá abrir a ferramenta.

 
 
 

A criação de perfis

Para começar a gravar um novo perfil, clique no ícone do cronômetro. Clique novamente para terminar a gravação. O perfil será imediatamente aberto. Você pode salvar o perfil como um arquivo JSON e importação salva perfis. A barra lateral à esquerda permite que você alterne entre vários perfis abertos.

 
 
 

Análise de perfis

Um perfil é algo como isto:

Ele consiste em quatro seções principais camadas horizontalmente:

  1. um conjunto de migalhas de pão que você pode usar para zoom in e out
     
    um cronograma taxa de quadros
  2. um cronograma para a execução de código plataforma
    a saída detalhada do perfil de amostragem JavaScript
 
 
 

O cronograma taxa de quadros

 
O cronograma taxa de quadros dá-lhe uma visão geral de capacidade de resposta do navegador no período coberto pelo perfil.

Um quadro encapsula o trabalho do navegador precisa fazer a fim de pintar em resposta a algum evento. Por exemplo, se movendo o mouse sobre algum elemento página desencadeia alguns JavaScript que muda a aparência do elemento, e que desencadeia um refluxo e um repaint, depois de todo esse trabalho precisa ser concluída nesse quadro. Se demorar muito tempo para o navegador para processar o quadro, em seguida, o navegador irá aparecer sem resposta (janky).

A ferramenta de desempenho leva um timestamp quando o navegador termina um quadro, e usa isso para manter o controle da taxa de quadros:

O eixo x é o tempo durante o período de perfil, e há três anotações: a taxa de quadro de destino (sempre 60 quadros por segundo), a média de frames, ea menor taxa de quadros.
 
 

Execução de código Platform

Isto dá-lhe uma visão geral de execução de código no período coberto pelo perfil. Tal como acontece com o cronograma taxa de quadros, o eixo x representa o tempo durante o período de perfis, e as amostras são colocadas para fora como barras verticais na ordem em que foram tiradas, esquerda para a direita:

A altura de cada barra representa a profundidade da pilha de chamadas neste ponto.

A ferramenta de desempenho examina a pilha de chamadas e descobre os tipos de coisas o código JavaScript está fazendo, e divide o bar em cores de acordo:

Network Envio e processamento de pedidos e respostas de rede
JIT Compilação de código JavaScript
GC Garbage collection
Inputs & events Eventos como de mouse ou eventos de DOM
Styles Análise de CSS
Graphics Inclue manipulção de reflows e repaints assim como WebGL
Storage Na maioria das vezes é o IndexedDB
Gecko Tudo o que não se encaixa em nenhuma das outras categorias

Passando o cursor sobre a chave de cor de uma dada categoria desvanece as outras categorias:

Essa é a visão de linhas alinhadas com a taxa de quadros em um determinado tempo, assim você poderá correlacionar a lentidão da taxa de quadros com operações Javascript particulares.

Note que essa visão mostra tudo o que a plataforma está fazendo, não apenas o seu próprio código.

Perfil de amostragem JavaScript

O profiller periodicamento gera amostras do estado do motor Javascript e registra a pilha para o código em execução no momento em que a amostra foi colhida. Estatiscamente, o número de amostras colhidas que executavam uma determinada função corresponde à quantidade de tempo que o navegador está gastando para executá-la, assim é possível identificar gargalos em seu código.

Por exemplo, considere um programa como este:

function doSomething() {
  var x = getTheValue();
  x = x + 1;                // -> A (from the top level)
  logTheValue(x);
}

function getTheValue() {
  return 5;                 // -> B (from doSomething())
}

function logTheValue(x) {
                            // -> C (from doSomething())
                            // -> D (from doSomething())
                            // -> E (from the top level)
 console.log(x);
}

doSomething();

logTheValue(6);

Suponha que nós executamos o programa com o profile ativado, e no tempo que leva para executar, o profile registrou 5 amostras, como indicado nos comentários do código acima.

Four are taken from inside doSomething(). Of those, A is directly inside doSomething(). B is inside getTheValue(), and C and D are inside logTheValue(). Finally, the program makes a call to logTheValue() from the top level, and we get a sample there, too. So the profile would consist of five stack traces, like this:

Sample A: doSomething()
Sample B: doSomething() > getTheValue()
Sample C: doSomething() > logTheValue()
Sample D: doSomething() > logTheValue()
Sample E: logTheValue()

This obviously isn't enough data to tell us anything, but with a lot more samples we might be able to conclude that logTheValue() is the bottleneck in our code.

Profile structure

The sampling profiler's details pane looks something like this:It presents the samples collected as a table.

Samples

The number of samples that were taken in which the corresponding "Function" appeared in the call stack. For example, given the profiling example above, the corresponding "Samples" and "Functions" columns would look like:

4  doSomething()
2  > logTheValue()
1  > getTheValue()
1  logTheValue()

Note that logTheValue() appears twice, because it's called from two different places.

Function This includes the function name, source file, line number and domain that served the file. Clicking on the file name takes you to that file in the Debugger.
Total Cost A direct translation of the "Samples" column into a percentage.
Self Cost

The "Samples" column includes not only samples that were taken while the JavaScript engine was executing this function, but also samples taken while executing functions called by this function.

For example, in the example above we record 4 samples for doSomething(), but 3 of those samples were taken while the JavaScript engine was executing functions called by doSomething().

"Self Cost" is the number of samples taken while the JavaScript engine was actually executing this function, translated into a percentage. In the example above, the "Self Cost" for doSomething() is 20% (1 sample out of 5 in total was taken while actually executing the function).

Total Time

A statistical estimate of the amount of time spent inside the function, given the number of samples that were taken in it.

This value is derived from "Samples" but is not a direct translation, because we don't always take samples at exactly the right time, so we attempt to correct for this irregularity.

Self Time

A statistical estimate of the amount of time spent executing the function, exclusive of any functions called by this function.

Just as "Total Time" is not a direct translation of  "Samples", so "Self Time" is not a direct translation of "Self Cost".

For a deeper look into the way the sampling profiler presents data, see this walkthrough of a profile.

Inverting the call tree

New in Firefox 36

By default, the profiler shows you the call tree from the root to the leaves, like a normal call stack. That is, from each top-level function to the functions it calls, then to the functions they call, and so on:

4  doSomething()
2  > logTheValue()
1  > getTheValue()
1  logTheValue()

This seems logical as it's the temporal order in which the stack is built up, and it's also conventional to represent a call stack in that way. However, often the places where you're spending time are deep in the call tree. So when you look at a profile you'll often click through many higher-level functions with a low "Self Cost", and it can be hard to see the places you're actually spending most of the time.

From Firefox 36 there's a new checkbox in the profiler labeled "Invert Call Tree". If you select this option, the profiler:

  • makes a list of all functions with a Self Cost greater than zero: that is, functions which were actually executing when the sample was taken
  • orders the list by the number of samples taken while in that function
  • for each entry in the list, shows the call stack backwards to the top-level function.

This is usually a more effective way to highlight where your code is spending its time.

Zooming in

Clicking on a row highlights all the samples in the timeline view in which this function appears:If you hover over a row you'll see a magnifying glass at the right-hand end of it. Clicking the magnifying glass makes that row the root: that is, it presents the entire profile as if only that row and the rows underneath it exist:

Note that this also zooms in on the section of the profile in which these samples were taken.

Zooming in

If you click and drag in either the frame rate timeline or the sampling profiler timeline, then:

  • a section of the timeline is highlighted
  • the sampling profiler details view now shows only samples that were recorded in that section
  • you'll see a "+" appear in the toolbar at the top:

Click the "+", and the highlighted section is expanded to fill the timeline. The toolbar at the top now shows the section as a separate breadcrumb:

You can switch between the complete profile and the section using the breadcrumbs. You can also zoom in on a subsection within the section, and that will then appear as a third breadcrumb in the toolbar:

 

 

Etiquetas do documento e colaboradores

 Colaboradores desta página: IgorGoncalves, ricardolima89, gilton, samuelpontes
 Última atualização por: IgorGoncalves,