O V8 usa armazenamento em cache de código para guardar o código gerado de scripts usados frequentemente. A partir do Chrome 66, estamos armazenando mais código em cache ao gerar o cache após a execução de alto nível. Isso resulta em uma redução de 20–40% no tempo de análise e compilação durante o carregamento inicial.
A cada seis semanas, criamos um novo branch do V8 como parte do nosso processo de lançamento. Cada versão é criada a partir do Git master do V8 imediatamente antes de um marco Beta do Chrome. Hoje estamos felizes em anunciar nosso mais novo branch, versão 6.6 do V8, que está em fase beta até seu lançamento coordenado com o Chrome 66 Stable nas próximas semanas. O V8 v6.6 está repleto de recursos voltados para desenvolvedores. Este post oferece uma prévia de alguns destaques em antecipação ao lançamento.
TL;DR: A partir do Chrome 66, o V8 compila o código-fonte JavaScript em uma thread de fundo, reduzindo o tempo gasto na compilação na thread principal entre 5% a 20% em sites típicos.
Desde a versão 41, o Chrome suporta parsing de arquivos fonte JavaScript em uma thread de fundo via a API StreamedSource do V8. Isso permite que o V8 comece a fazer o parsing do código-fonte JavaScript assim que o Chrome baixa o primeiro pedaço do arquivo da rede, continuando o parsing em paralelo enquanto o Chrome transmite o arquivo pela rede. Isso pode proporcionar melhorias consideráveis no tempo de carregamento, uma vez que o V8 pode praticamente terminar o parsing do JavaScript quando o download do arquivo é concluído.
Depurar vazamentos de memória no Chrome 66 ficou muito mais fácil. As DevTools do Chrome agora podem rastrear e fazer snapshot de objetos DOM C++ e exibir todos os objetos DOM alcançáveis a partir do JavaScript com suas referências. Este recurso é um dos benefícios do novo mecanismo de rastreamento em C++ do coletor de lixo V8.
TL;DR: A desserialização preguiçosa foi recentemente ativada como padrão no V8 v6.4, reduzindo o consumo de memória do V8 em mais de 500 KB por aba do navegador em média. Leia para saber mais!
Mas primeiro, vamos dar um passo atrás e ver como o V8 usa snapshots de heap para acelerar a criação de novos Isolates (que correspondem aproximadamente a uma aba do navegador no Chrome). Meu colega Yang Guo deu uma boa introdução sobre isso em seu artigo sobre snapshots de inicialização personalizada:
A cada seis semanas, criamos um novo branch do V8 como parte do nosso processo de lançamento. Cada versão é criada a partir do Git master do V8 imediatamente antes de um marco Beta do Chrome. Hoje estamos felizes em anunciar nosso novo branch, V8 versão 6.5, que está em beta até seu lançamento em coordenação com o Chrome 65 Stable em algumas semanas. O V8 v6.5 está cheio de recursos voltados para desenvolvedores. Este post fornece uma prévia de alguns destaques em antecipação ao lançamento.
ECMAScript 2015 introduziu várias novas estruturas de dados, como Map, Set, WeakSet e WeakMap, todas elas usam tabelas de hash internamente. Este post detalha as melhorias recentes no modo como o V8 v6.3+ armazena as chaves nas tabelas de hash.
Desde o lançamento inicial do Speedometer 1.0 em 2014, as equipes Blink e V8 têm usado o benchmark como um proxy para uso real de frameworks populares de JavaScript e conseguimos ganhos de velocidade consideráveis nesse benchmark. Verificamos independentemente que essas melhorias se traduzem em benefícios reais para os usuários, medindo contra sites reais e observando que as melhorias nos tempos de carregamento de páginas de sites populares também melhoraram a pontuação no Speedometer.
A cada seis semanas, criamos uma nova ramificação do V8 como parte do nosso processo de lançamento. Cada versão é ramificada a partir do Git master do V8 imediatamente antes de uma milestone Beta do Chrome. Hoje temos o prazer de anunciar nossa mais nova ramificação, V8 versão 6.4, que está na fase beta até seu lançamento em coordenação com o Chrome 64 Stable nas próximas semanas. O V8 v6.4 está repleto de novidades voltadas para desenvolvedores. Este post fornece uma prévia de alguns dos destaques em antecipação ao lançamento.
A cobertura de código fornece informações sobre se, e opcionalmente com que frequência, certas partes de uma aplicação foram executadas. É comumente usada para determinar quão bem um conjunto de testes avalia uma base de código específica.
Como desenvolvedor JavaScript, você pode frequentemente se encontrar em situações onde a cobertura de código pode ser útil. Por exemplo:
console.log para depuração estilo printf ou passar manualmente pelo código, a cobertura de código pode exibir informações ao vivo sobre quais partes de suas aplicações foram executadas.