Node.js por Baixo dos Panos #10 - Otimizações do Compilador
Tags: node, v8, computerscience, javascript
Published: 2020-05-21 18:50:27

_Photo por Michael Dziedzic no Unsplash_

Nos artigos anteriores, falamos sobre como o [Node.js](https://docs.microsoft.com/azure/javascript/?WT.mc_id=nodeunder-devto-ludossan) funciona por baixo dos panos e como o V8 compila o código com tanta eficiência, a maior parte dessa eficiência está relacionada a [otimizações do compilador](https://docs.microsoft.com/archive/msdn-magazine/2015/february/compilers-what-every-programmer-should-know-about-compiler-optimizations?WT.mc_id=nodeunder-devto-ludossan), portanto, neste artigo, finalmente conheceremos o que são e como eles funcionam!

Este é um breve resumo de várias [otimizações do compilador](https://docs.microsoft.com/archive/msdn-magazine/2015/february/compilers-what-every-programmer-should-know-about-compiler-optimizations? WT.mc_id = nodeunder-devto-ludossan) que o V8 pode executar no código. O objetivo deste artigo é apenas apresentar quais tipos de coisas estão incluídas quando dizemos "otimização". Não vamos nos aprofundar em como os compiladores fazem isso.

Todas as otimizações abaixo são feitas enquanto o compilador está analisando o código.

# On Stack Replacement

On Stack Replacement é a técnica de otimização que substitui um pedaço de código não otimizado por outro pedaço de código otimizado durante a execução. O V8 faz isso sempre que precisa otimizar uma única função ou o código em execução. Em resumo, On Stack Replacement significa que o stack frame atual será substituído por outro stack frame de código otimizado sem perder nenhuma outra informação, enquanto o código ainda está em execução. É como trocar os pneus de um carro no meio de uma corrida, com ele ainda correndo.

# Constant Folding

Substitui expressões constantes pelo seu valor final no tempo de compilação, em vez de fazer o cálculo no tempo de execução.

Exemplo:

*não compilado:*

```js
const j = 3 + 9
```

*compilado:*

```js
const j = 12
```

# Análise Indutiva de Variável

Em um loop, se uma variável for uma função linear simples da variável que estamos usando como índice, por exemplo, `const p = 4 * i + 1`, ela poderá ser atualizada adequadamente cada vez que a variável do loop for alterada.

Isso é chamado de redução de força, uma forma de otimização em que operações caras são substituídas por operações menos caras equivalentes, por exemplo, uma multiplicação cara é substituída por uma série de adições mais baratas.

Portanto o código acima seria substituído por algo como: `const p = (i + 1) + (i + 1) + (i + 1) + (i + 1)`

# Rematerialização

O ato de recalcular o valor de uma variável ao invés de puxar o valor já calculado da memória. Isso evita que a memória seja acessada muitas vezes.

# Remoção de Recursão

A recursão geralmente é muito cara, como vimos quando falamos sobre _Stack Overflow_. Os algoritmos recursivos chamados de _Tail Recursion_ (código que termina retornando uma chamada para si mesmo) podem ser convertidos em algoritmos iterativos, o que elimina os problemas da pilha. Isso geralmente é feito usando **[Tail Call Optimisations](https://en.wikipedia.org/wiki/Tail_call)**, que é o processo no qual você é capaz de evitar a alocação de um novo stackframe para uma função porque a função que está chamando a nova execução vai simplesmente retornar o valor que a nova execução calcular. Portanto, esta última chamada pode ser substituída pela própria função.

# Peephole Optimisations

Essas são geralmente executados no final do processo de compilação, após a geração do código da máquina. Essa técnica de otimização examina algumas instruções adjacentes (como olhar através de uma fechadura, daí o nome _peephole_) para ver se elas podem ser substituídas por uma única instrução ou uma sequência mais curta de instruções. 

Um exemplo é uma multiplicação por uma potência de 2, que pode ser substituída por um deslocamento à esquerda bit a bit. (que também é uma otimização de redução de força).

## Expansão Linear

Essa é a técnica de substituir a chamada para uma função pelo seu corpo. Isso economiza muito na hora de adicionar outro stack frame e é também uma grande oportunidade para otimizações específicas de parâmetros, mas isso tem um custo de espaço. Se o método for chamado várias vezes durante um programa, seu corpo será substituído várias vezes, o que pode levar a um código maior e mais pesado.

Geralmente, essa linearidade é muito útil para códigos de desempenho críticos que fazem um grande número de chamadas para procedimentos pequenos, portanto, há menos saltos.

## Inline Caching

Inline Caching se baseia na observação de que chamadas repetidas para o mesmo método tendem a ocorrer no mesmo tipo de objeto. A V8 mantém um cache do tipo de objetos que foram passados como parâmetro nas chamadas de método recentes e usa essas informações para fazer uma suposição sobre o tipo de objeto que será passado como parâmetro no futuro. Se essa suposição for boa, a próxima chamada poderá ignorar o processo de descobrir como acessar as propriedades do objeto e, em vez disso, usar as informações armazenadas de pesquisas prévias nas hidden classes (classes ocultas) desse objeto.

Isso se refere especificamente ao conceito de hidden classes porque, sempre que um método é chamado em um objeto específico, o mecanismo deve procurar a hidden class a fim de encontrar o offset de memória para essa propriedad. Após duas chamadas bem-sucedidas desse mesmo método para a mesma classe oculta, a V8 omite a pesquisa de classe oculta e adiciona o deslocamento a essa propriedade no próprio ponteiro de objeto. Isso aumenta muito a velocidade de execução.

# Eliminação de "Código Morto"

Esse processo elimina o código que nunca é chamado no programa. Ele faz isso, explicando por cima, passando por todos os bytecodes durante a execução do programa, gera um gráfico e elimina as partes que não pertencem a nenhum caminho de código.

# Reordenação de código

A reordenação de bloco de código altera a ordem dos blocos básicos em um programa para reduzir ramificações condicionais e melhorar a "localidade de referência", que é a tendência de um processador acessar o mesmo conjunto de locais de memória repetidamente por um curto período de tempo.

# Jump Threading

Saltos condicionais consecutivos baseados total ou parcialmente na mesma condição podem ser mesclados. Por exemplo: `if (c) { foo; } if (c) { bar; }` vira `if (c) { foo; bar; }`

# Trampolines

Muitas CPUs possuem sub-rotinas menores, instruções de chamada para acessar pouca memória. O compilador pode economizar espaço usando essas pequenas chamadas no corpo da função. Multiplicando a economia de espaço da refatoração de código.

# Eliminação de Expressões Comuns

Sempre que repetimos subexpressões, como em `(a + b) * 2 + (a + b)`, a *subexpressão comum* é `a + b`. Portanto, o compilador calcula o valor de `a + b` apenas uma vez e usa *constant folding* para substituí-lo na chamada da expressão, assumindo que a mesma **não** mude ao longo do tempo.

# Conclusão

Você conseguiu! Você finalmente chegou ao final de nossa série de 10 partes sobre o Node.js por baixo dos panos! Espero que você tenha gostado e tenha se sentido um pouco mais animado para saber mais!

Abaixo, deixarei todas as referências que usei para compor todos esses artigos e também um link para [o rascunho do artigo original no meu GitHub](https://github.com/khaosdoctor/my-notes/blob/master/node/ node-under-the-hood.md). É isso aí! Muito obrigado por ler e me dar um feedback sobre a série :D

Não deixe de acompanhar mais do meu conteúdo no [meu blog](https://blog.lsantos.dev/?utm_source=devto&utm_medium=article&utm_campaign=node_under_the_hood) e se [inscreva na newsletter](https://blog.lsantos.dev/signup?utm_source=devto&utm_medium=article&utm_campaign=node_under_the_hood) para receber notícias semanais!

# Referências

- [LibUV](https://github.com/libuv/libuv?WT.mc_id=devto-blog-ludossan)
- [N-API](https://nodejs.org/api/n-api.html)
- [Esprima AST generator](https://esprima.org)
- [TurboFan docs](https://v8.dev/docs/turbofan)
- [TurboFan JIT](https://v8.dev/blog/turbofan-jit)
- [Native modules](https://nodejs.org/api/addons.html)
- [História do JS](https://en.wikipedia.org/wiki/JavaScript)
- [História do Node.js](https://en.wikipedia.org/wiki/Node.js)
- [Tipos de elementos no V8](https://v8.dev/blog/elements-kinds)
- [WHATVG spec para microtasks](https://html.spec.whatwg.org/multipage/webappapis.html#task-queue)
- [V8 Under the Hood](https://slides.com/igorfranca/v8-under-the-hood#/)
- [Fonte do módulo FS](https://github.com/nodejs/node/blob/master/lib/fs.js?WT.mc_id=devto-blog-ludossan)
- [Motivos para a criação do TurboFan](https://nodesource.com/blog/why-the-new-v8-is-so-damn-fast/)
- [Source do método read_file_context do FS](https://github.com/nodejs/node/blob/master/lib/internal/fs/read_file_context.js?WT.mc_id=devto-blog-ludossan)
- [Exemplos do V8 Under The Hood](https://github.com/Horaddrim/v8-under-the-hood?WT.mc_id=devto-blog-ludossan)
- [Internals do Node na lib Crypto](https://medium.com/front-end-weekly/internals-of-node-advance-node-%EF%B8%8F-8612f6a957d7)
- [Microtasks e Macrotasks](https://stackoverflow.com/questions/25915634/difference-between-microtask-and-macrotask-within-an-event-loop-context)
- [Lauching ignition and turbofan](https://v8.dev/blog/launching-ignition-and-turbofan)
- [Performance no V8](https://v8-io12.appspot.com/index.html)
- [Entendendo Inline caching](https://github.com/sq/JSIL/wiki/Optimizing-dynamic-JavaScript-with-inline-caches?WT.mc_id=devto-blog-ludossan)
- [Sea of Nodes](http://www.masonchang.com/blog/2010/8/9/sea-of-nodes-compilation-approach.html)
- [Sea of Nodes (explicação)](http://grothoff.org/christian/teaching/2007/3353/papers/click95simple.pdf)
- [Bytecodes no NodeJS](https://medium.com/@drag13dev/https-medium-com-drag13dev-how-to-get-javascript-bytecode-from-nodejs-7bd396805d30)
- [Entendendo bytecodes no V8](https://medium.com/dailyjs/understanding-v8s-bytecode-317d46c94775)
- [Lista de Vytecodes do V8](https://github.com/v8/v8/blob/master/src/interpreter/bytecodes.h)
- [Como funciona o GC do Node.js](https://blog.risingstack.com/finding-a-memory-leak-in-node-js/)
- [Gerador de códigos interpretados](https://github.com/v8/v8/blob/master/src/interpreter/interpreter-generator.cc?WT.mc_id=devto-blog-ludossan)
- [O que são pilhas?](https://en.wikipedia.org/wiki/Stack_(abstract_data_type))
- [O que são filas?](https://www.studytonight.com/data-structures/queue-data-structure)
- [Lista de otimizações](https://en.wikipedia.org/wiki/Optimizing_compiler)
- [O que são Static Single Assignments?](https://wingolog.org/archives/2011/07/12/static-single-assignment-for-functional-programmers)
- [On stack replacement no V8](https://wingolog.org/archives/2011/06/20/on-stack-replacement-in-v8)
- [Por que o node é tão rápido](https://blog.ghaiklor.com/2015/11/14/why-nodejs-is-so-fast/)
- [You don't know Node.js](https://medium.com/edge-coders/you-dont-know-node-6515a658a1ed)
- [V8 - A tale of Turbofan](https://dzone.com/articles/v8-behind-the-scenes-and-a-tale-of-turbofan)
- [Dicas de otimização no V8](https://blog.ghaiklor.com/2016/04/05/optimisations-tricks-in-v8/)
- [V8 Internals](https://slidr.io/mathiasbynens/v8-internals-for-javascript-developers#1)
- [Como o V8 otimiza o código](https://blog.ghaiklor.com/2016/03/25/how-v8-optimises-javascript-code/)
- [Minhas notas pessoais sobre o V8](https://github.com/khaosdoctor/my-notes/blob/master/node/V8.md?WT.mc_id=devto-blog-ludossan)
- [[LIVRO] Node.js Under the Hood](https://resources.risingstack.com/Node.js+at+Scale+Vol.+2+-+Node.js+Under+the+Hood.pdf)
- [Descobrindo de-optimizações no Node.js](https://blog.ghaiklor.com/2016/05/16/tracing-de-optimisations-in-nodejs/)
- [Entendendo promises de uma vez por todas](https://medium.com/trainingcenter/entendendo-promises-de-uma-vez-por-todas-32442ec725c2)
- [Engine de Renderização do JS](https://blog.sessionstack.com/how-javascript-works-the-rendering-engine-and-tips-to-optimize-its-performance-7b95553baeda)
- [Alocação de Memória em Javascript](https://blog.sessionstack.com/how-javascript-works-memory-management-how-to-handle-4-common-memory-leaks-3f28b94cfbec)
- [Como o JS funciona](https://blog.sessionstack.com/how-does-javascript-actually-work-part-1-b0bacc073cf)
- [Minhas guidelines para a palestra (primeira versão, incompleta) sobre esse tópico](https://github.com/khaosdoctor/my-notes/blob/master/node/Guideline%20de%20palestra%20the%20conf%202019.pdf?WT.mc_id=devto-blog-ludossan)
- [How JavaScript works: inside the V8 engine + 5 tips on how to write optimized code](https://blog.sessionstack.com/how-javascript-works-inside-the-v8-engine-5-tips-on-how-to-write-optimized-code-ac089e62b12e)
- [[VIDEO] High performance JS in V8](https://www.youtube.com/watch?v=YqOhBezMx1o)
- [[VIDEO] Ryan Dahl's Introduction to Node.js](https://www.youtube.com/watch?v=jo_B4LTHi3I)
- [[VIDEO] BlinkOn 6 Day 1 Talk 2: Ignition - an interpreter for V8](https://www.youtube.com/watch?v=r5OWCtuKiAk)
- [[VIDEO] MNUG 2017.03.23 TurboFan: A new code generation architecture for V8](https://www.youtube.com/watch?v=M1FBosB5tjM)
- [[VIDEO] Benedikt Meurer: A Tale of TurboFan: Four years that changed V8 forever](https://www.youtube.com/watch?v=cvybnv79Sek)
- [[VIDEO] Marja Hölttä: Parsing JavaScript - better lazy than eager? | JSConf EU 2017](https://www.youtube.com/watch?v=Fg7niTmNNLg)
- [VIDEO] [Franziska Hinkelmann](https://dev.to/fhinkel): [JavaScript engines - how do they even? | JSConf EU 2017](https://www.youtube.com/watch?v=p-iiEDtpy6I?WT.mc_id=devto-blog-ludossan)
- [[VIDEO] TDC 2017 - Stadium: Como o Node funciona por Kirmayr Tomaz (in Portuguese)](https://pt-br.eventials.com/Globalcode/tdc-sp-2017-stadium-quarta-5/?WT.mc_id=devto-blog-ludossan)