12 postagens marcadas com "benchmarks"

No V8, estamos constantemente buscando melhorar o desempenho do JavaScript. Como parte desse esforço, recentemente revisamos o conjunto de benchmarks JetStream2 para eliminar gargalos de desempenho. Este post detalha uma otimização específica que realizamos e que resultou em uma melhoria significativa de 2.5x no benchmark async-fs, contribuindo para um aumento perceptível na pontuação geral. A otimização foi inspirada pelo benchmark, mas padrões como esses aparecem em código do mundo real.

Bem-vindo ao emocionante mundo do V8, onde velocidade não é apenas uma característica, mas um estilo de vida. Enquanto nos despedimos de 2023, é hora de celebrar as impressionantes realizações que o V8 alcançou este ano.

Através de otimizações inovadoras de desempenho, o V8 continua a expandir os limites do que é possível no cenário em constante evolução da Web. Introduzimos um novo compilador de nível intermediário e implementamos várias melhorias na infraestrutura do compilador de alto nível, no runtime e no coletor de lixo, o que resultou em ganhos significativos de velocidade em todos os aspectos.

Durante seu estágio de três meses na equipe do V8, Hai Dang trabalhou na melhoria do desempenho de [...array], [...string], [...set], [...map.keys()] e [...map.values()] (quando os elementos espalhados estão no início do literal do array). Ele até tornou Array.from(iterable) muito mais rápido também. Este artigo explica alguns dos detalhes técnicos de suas mudanças, que estão incluídas no V8 a partir da versão v7.2.

O processamento assíncrono em JavaScript tradicionalmente tinha a reputação de não ser particularmente rápido. Para piorar, depurar aplicativos JavaScript ao vivo — especialmente servidores Node.js — não é uma tarefa fácil, especialmente quando se trata de programação assíncrona. Felizmente os tempos estão mudando. Este artigo explora como otimizamos funções assíncronas e promessas no V8 (e até certo ponto em outros motores JavaScript também), e descreve como melhoramos a experiência de depuração para código assíncrono.

DataViews são uma das duas maneiras possíveis de realizar acessos de memória em baixo nível no JavaScript, sendo a outra TypedArrays. Até agora, os DataViews eram muito menos otimizados do que os TypedArrays no V8, resultando em desempenho inferior em tarefas como cargas de trabalho intensivas em gráficos ou na decodificação/codificação de dados binários. As razões para isso foram principalmente escolhas históricas, como o fato de que asm.js escolheu TypedArrays em vez de DataViews, incentivando os motores a focarem no desempenho dos TypedArrays.

Este mês marca o aniversário de 10 anos do lançamento não apenas do Google Chrome, mas também do projeto V8. Este post apresenta uma visão geral dos principais marcos do projeto V8 nos últimos 10 anos, bem como nos anos anteriores, quando o projeto ainda era secreto.

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.

O desempenho do JavaScript sempre foi importante para a equipe do V8, e neste post gostaríamos de discutir um novo Benchmark de Ferramentas Web que temos usado recentemente para identificar e corrigir alguns gargalos de desempenho no V8. Você já pode estar ciente do forte compromisso do V8 com o Node.js, e este benchmark estende esse compromisso ao executar testes de desempenho especificamente baseados em ferramentas comuns de desenvolvedores construídas sobre Node.js. As ferramentas no Benchmark de Ferramentas Web são as mesmas usadas por desenvolvedores e designers hoje para criar sites modernos e aplicativos baseados em nuvem. Continuando nossos esforços contínuos para focar no desempenho do mundo real em vez de benchmarks artificiais, criamos o benchmark usando código real que os desenvolvedores executam diariamente.

Os proxies são parte integrante do JavaScript desde o ES2015. Eles permitem interceptar operações fundamentais em objetos e personalizar seu comportamento. Proxies formam uma parte central de projetos como jsdom e a biblioteca RPC Comlink. Recentemente, fizemos um grande esforço para melhorar o desempenho dos proxies no V8. Este artigo lança luz sobre padrões gerais de melhoria de desempenho no V8 e, em particular, para proxies.

A história dos benchmarks de JavaScript é uma narrativa de constante evolução. À medida que a web se expandiu de simples documentos para aplicações dinâmicas no lado do cliente, novos benchmarks de JavaScript foram criados para medir cargas de trabalho que se tornaram importantes para novos casos de uso. Essa constante mudança deu aos benchmarks individuais tempos de vida finitos. À medida que os navegadores web e as implementações de máquinas virtuais (VM) começam a super-otimizar casos de teste específicos, os benchmarks deixam de ser proxies eficazes para seus usos originais. Um dos primeiros benchmarks de JavaScript, SunSpider, ofereceu incentivos iniciais para o envio rápido de compiladores otimizadores. No entanto, à medida que os engenheiros de VM descobriram as limitações dos microbenchmarks e encontraram novas maneiras de otimizar ao redor das limitações do SunSpider limitations, a comunidade de navegadores aposentou SunSpider como um benchmark recomendado.