O que há de novo no nó 12

Recentemente , o nó 12 recebeu o codinome Erbium , cujo suporte a longo prazo (LTS) durará de outubro de 2019 a abril de 2022.


A nova versão possui muitos benefícios e melhorias no tempo de execução. Além disso, considerando que, sob o capô do V8, o nó também receberá todas as melhorias no mecanismo.




Suporte de import/export


O nó entra na fase 3 no caminho para os módulos ECMAScript . Inicialmente, esse recurso estava disponível apenas com o --experimental-modules . No momento em que o Nó muda para o LTS, está planejado remover a necessidade de usar esse sinalizador.


A sintaxe usando import/export se preferível ao trabalhar com módulos para desenvolvedores js desde a padronização no ES6, e a equipe por trás do Node trabalhou diligentemente no suporte nativo. Esse recurso estava disponível experimentalmente com o nó 8.0 da fase 0. A versão atual é um grande passo nessa direção. Os navegadores mais populares já suportam esse recurso com <script type="module"> .


Desde a fase 3, haverá suporte para três opções de import dos modelos ES:


 //    import module from 'module' //   import { namedExport } from 'module' //     import * as module from 'module' 

Os módulos baunilha só podem ser exportados da maneira padrão:


 import module from 'cjs-library' 

Você pode usar import() para carregar em tempo de execução. import() retorna Promise e trabalha com os modelos ES e as bibliotecas CommonJS.


V8


O nó 12 será executado inicialmente na V8 7.4 e, eventualmente, será atualizado para a 7.6. A equipe V8 concordou em fornecer uma ABI (Application Binary Interface). Melhorias notáveis ​​na V8 7.4 são melhorias de desempenho para execução mais rápida do JavaScript, melhor gerenciamento de memória e suporte aprimorado à sintaxe do ECMAScript.



Rastreios de pilha assíncrona


Vamos olhar para este código:


 async function testAsyncStacktrace() { await killme(); return 42; } async function killme() { await Promise.resolve(); throw new Error('#Feelsbadman'); } testAsyncStacktrace().catch(error => console.log(error.stack)); 

Nas versões mais antigas, você obterá algo como isto:


 Error: #Feelsbadman at killme (test.js:8:11) at process._tickCallback (internal/process/next_tick.js:68:7) at Function.Module.runMain (internal/modules/cjs/loader.js:721:11) at startup (internal/bootstrap/node.js:228:19) at bootstrapNodeJSCore (internal/bootstrap/node.js:576:3) 

Como você pode ver, a mensagem não menciona testAsyncStacktrace . E agora o --async-stack-traces está ativado por padrão, e o log ficará assim:


 Error: #Feelsbadman at killme (test.js:8:11) at async testAsyncStacktrace (test.js:2:5) 

Chamada acelerada quando o número de argumentos não corresponde


No JavaScript, é perfeitamente aceitável chamar funções com menos / mais argumentos (ou seja, passar menos ou mais parâmetros formais declarados). No primeiro caso, está subaplicado e , no segundo, está com subaplicação . No caso de um número insuficiente de argumentos, os parâmetros serão undefined , enquanto no caso de um grande número de parâmetros, eles são simplesmente ignorados.


No entanto, as funções JavaScript ainda podem obter os parâmetros reais usando os arguments , objeto de parâmetros de descanso ou mesmo usando os arguments Function.prototype.arguments não padronizados nas funções do modo desleixado . Como resultado, os mecanismos JavaScript devem fornecer uma maneira de obter os parâmetros reais. Na V8, isso é feito usando a técnica de adaptação de argumentos . Infelizmente, esses métodos afetam o desempenho.


Em alguns cenários, o V8 ignora completamente a adaptação de argumentos , reduzindo a sobrecarga de chamadas em até 60%.



Detalhes podem ser encontrados no documento .


Análise acelerada


No Chrome, scripts grandes o suficiente são analisados ​​em fluxo contínuo nos threads de trabalho durante o carregamento. A V8 7.4 corrigiu o problema com o desempenho da decodificação UTF-8, o que levou a uma aceleração de 8%.



Cada gota no diagrama representa uma das melhorias de desempenho no analisador de fluxo.


await aprimorada


Juntamente com o --async-stack-traces , o --harmony-await-optimization está agora ativado por padrão. Detalhes aqui .


Campos de classe privada


A capacidade de usar campos particulares na V8 foi migrada para o nó. Esses campos não estão disponíveis fora da classe. Para criá-los, você precisa especificar # antes da variável.


 class HelloThere { #hidden = 'Hidden'; get hidden() { return this.#hidden; } set hidden(txt) { this.#hidden = txt; } hi() { console.log(`Hello, ${this.#hidden}`); } } 

Ao tentar acessar #hidden de fora, você recebe um erro de sintaxe.


 const hello = new HelloThere(); hello.#hidden = 'Visible'; // -> SyntaxError console.log(hello.#hidden); // -> SyntaxError 

Início rápido


O nó 12 usará o cache para bibliotecas internas antes da construção e incorporação como binários. Devido ao uso desse cache no encadeamento principal, o horário de início será reduzido em 30%.


TLS e segurança


A Noda agora suporta o TLS 1.3, que oferece segurança aprimorada e reduz a latência. O TLS 1.3 mudou bastante o protocolo e está se integrando ativamente à rede. A introdução do TLS 1.3 aumentará a confidencialidade dos dados do usuário, além de acelerar o processamento de solicitações, reduzindo o tempo para handshake em HTTPS. Além disso, o TLS 1.0 e 1.1 são desativados por padrão e os métodos descontinuados foram removidos da crypto .


Tamanho dinâmico do quadril


Anteriormente, o tamanho de heap V8 padrão de 700 MB (sistemas de 32 bits) ou 1400 MB (sistemas de 64 bits) era usado. Agora, o nó determinará os tamanhos de heap com base na memória disponível para otimizar os recursos usados ​​da máquina.


A capacidade de despejar quadril


O nó 12 fornece a capacidade de despejar pilhas, facilitando a detecção de problemas de memória. Detalhes podem ser encontrados aqui e aqui .


Relatórios de diagnóstico experimental


O Noda oferece ferramentas mais poderosas para diagnosticar problemas (desempenho, uso da CPU, memória, falhas etc.) dentro do aplicativo, fornecendo um recurso experimental para relatórios.


Melhorias ao trabalhar com módulos nativos


O nó 12 continua a tendência de simplificar o trabalho com a N-API . Esta versão possui suporte aprimorado, especialmente ao trabalhar com threads de trabalho.


Conclusão


O nó 12 tem muitas melhorias. O CHANGELOG completo pode ser visualizado no Github e no próprio site .

Source: https://habr.com/ru/post/pt450292/


All Articles