Como os diversos projetos de otimização Javascript afetar o desempenho DOM?

Question

Há um monte de capital C, o capital S informática entrar em Javascript através dos projectos TraceMonkey, Squirrelfish, e V8. Algum destes projectos (ou outros) de endereço o desempenho das operações DOM, ou são puramente Javascript computação relacionados?

Answer 1

O desempenho das operações de puro dom (getElementById / Tagname / Selector, nextChild, etc) não são afetados como eles já estão em puro C ++.

Como as melhorias do motor JS irá afetar o desempenho não depende até certo ponto sobre as técnicas específicas utilizadas para as melhorias de desempenho, bem como o desempenho da ponte dom-> JS.

Um exemplo do primeiro é a dependência do TraceMonkey em todas as chamadas, sendo a funções JS. Porque um traço efetivamente inlines o caminho de execução de qualquer ponto onde a JS bate código que não pode ser embutido (código nativo, verdadeiro recursão polimórfica, manipuladores de exceção) o traço é abortado e execução cai de volta para o intérprete. Os desenvolvedores TM estão fazendo um monte de trabalho para melhorar a quantidade de código que pode ser rastreada (incluindo manipulação recursão polimórfica), no entanto realista traçado entre as chamadas de funções nativas arbitrários (por exemplo. O DOM) não é viável. Por essa razão eu acredito que eles estão olhando para implementar mais do DOM em JS (ou pelo menos de uma forma amigável JS). Dito isto, quando o código é TM rastreável pode fazer um trabalho excepcionalmente bom como ele pode diminuir a maioria dos "objetos" para equivalentes mais eficiente e / ou nativo (por exemplo. Ints de uso da máquina em vez da implementação JS Number).

JavaScriptCore (que é onde SquirrelFish extrema vive) e V8 tem uma abordagem mais semelhante em que ambos JIT todo o código JS imediatamente e código de produto que é mais especulativa (ex. Se você estiver fazendo a*b eles geram código que assume a e b são números e cai de volta ao código excepcionalmente lento se eles não são). Isto tem uma série de benefícios ao longo do traçado, ou seja, que você pode JIT todo o código, independentemente de saber se é ou não chama código nativo / gera exceções, etc, o que significa que uma única chamada DOM não vai destruir o desempenho. A desvantagem é que todo o código é especulativo - TM irá chamadas em linha para os Math.floor, etc, mas a melhor JSC / V8 pode fazer seria equivalente a a=Math.floor(0.5) -> a=(Math.floor == realFloor) ? inline : Math.floor(0.5) isso tem custos, tanto em desempenho e uso de memória, ele também não é particularmente viável. A razão para isso é a compilação da frente para cima, enquanto TM somente o código EIC depois do prazo (e por isso sabe exatamente qual a função foi chamado) JSC e V8 não têm nenhuma base real para fazer tal suposição e, basicamente, tem que adivinhar (e, atualmente, nem tentativas isto). A única coisa que V8 e JSC fazer para tentar compensar este problema é rastrear o que viram no passado e incorporar em que o caminho de execução, tanto para uso uma combinação de técnicas para fazer isso caching, em casos especialmente quentes eles reescrever pequenas porções do fluxo de instruções e, em outros casos, eles manter-se fora de caches banda. De um modo geral, se você tiver o código que vai

a.x * a.y

V8 e JSC irá verificar o 'tipo implícito' / 'Estrutura' duas vezes - uma vez para cada acesso, e depois verificar que a.x e a.y são ambos os números, enquanto TM irá gerar o código que verifica o tipo de a apenas uma vez, e pode (todas as coisas são iguais) a.x basta multiplicar e a.y sem verificar que eles são números.

Se você está olhando para a velocidade de execução pura atualmente há algo de um saco misto como cada motor parece fazer melhor em determinadas tarefas do que outros - vitórias TraceMonkey em muitos testes de matemática pura, V8 ganha em casos muito dinâmicas, JSC ganha se há uma mistura. É claro que, enquanto isso é verdade hoje pode não ser amanhã, como todos nós estamos trabalhando duro para melhorar o desempenho.

A outra questão que eu mencionei foi o DOM <-> custo de ligação JS - isso pode realmente desempenhar um papel muito significativo no desempenho da web, o melhor exemplo disso é o Safari 3.1 / 2 vs Chrome na referência Dromaeo. Chrome é baseado fora do ramo Safari 3.1 / 2 do WebKit, por isso é razoavelmente seguro supor DOM semelhantedesempenho (diferença compilador poderia causar algum grau de variação). Neste referência Safari 3.1 / 2 realmente bate Chrome, apesar de ter um motor de JS que é claramente muito mais lento, este é basicamente devido a ligações mais eficientes entre JSC / WebCore (o dom / prestação / etc de WebKit) e V8 / WebCore

Atualmente olhando para os vínculos DOM do TM parece injusto que não tenham concluído todo o trabalho que eles querem fazer (infelizmente) de modo que apenas voltar a cair o intérprete: - (

..

Errmmm, que passou um pouco mais longo do que o pretendido, tão curta resposta à pergunta inicial é "depende": D

Answer 2

Eles são puro JavaScript. A menos que uma determinada chamada de método DOM é implementado em JS, eles terão pouco efeito (não quer dizer que não tem sido o trabalho feito na redução do sobrecarga de tais chamadas no entanto ).

otimização DOM é um todo 'nother chaleira de esquilos macacos aranhas peixe ... O layout e até mesmo motores de renderização entram em jogo, e cada navegador tem a sua própria estratégia de implementação e otimização.