javascript-high-performance

# Habilidade de IA: JavaScript High Performance Esta skill orienta a inteligência artificial a atuar como especialista em **performance de JavaScript**, cobrindo desde o profiling com as ferramentas dos navegadores até a arquitetura de código (mutabilidade, streams, workers, formatos de dados e WASM), baseada na obra *Hands-On JavaScript High Performance* (Justin Scherer, Packt). > 📖 **Referência canônica**: consulte [references/js-high-performance-book-guide.md](references/js-high-performance-book-guide.md) para o resumo por capítulo do livro e [examples/performance-patterns.md](examples/performance-patterns.md) para os padrões práticos. --- ## 🧭 Diretriz Geral - **Meça antes de otimizar**: use a aba Performance do Chrome DevTools para localizar o gargalo real (scripting, rendering, painting) — nunca otimize com base em suposições. - **Tudo é trade-off**: imutabilidade dá segurança à custa de velocidade/memória; coleções nativas batem bibliotecas; MessagePack pode não ser menor nem mais rápido que JSON nativo. Escolha consciente, não dogma. - **Prefira as primitivas do runtime**: o motor (V8 etc.) otimiza built-ins melhor que bibliotecas; evite camadas de abstração em hot paths. - **Mantenha a main thread livre**: qualquer processamento > ~16 ms deve ser offloaded para Workers, streams ou WASM. --- ## 🔍 1. Profiling e Observabilidade ### Abas do Chrome DevTools - **Performance**: gravação de timeline de runtime (Scripting/Rendering/Painting, flame chart de call stacks, event log). Use para achar funções de longa duração, forced reflows e GC pauses. - **Memory**: heap snapshots (comparação entre snapshots para detectar memory leaks — objetos retidos entre capturas), allocation instrumentation e allocation timeline. - **Rendering**: FPS meter e paint flashing para detectar layouts/paints excessivos em tempo real. - Outros motores: Safari (Web Inspector com Timeline), Firefox (Performance tools) e Edge (fork do Chromium) — motores diferentes otimizam diferente, valide em múltiplos navegadores. ### Benchmarking correto (jsPerf e afins) - Cuidado com **otimizações do motor** que distorcem resultados (mortal code, dead code elimination) — consuma resultados das funções de teste. - Compare em **múltiplos navegadores/motores**; nenhum resultado de um único motor é definitivo. - Remova código extrano dos casos de teste — qualquer trabalho extra enviesa asmedições. --- ## ⚖️ 2. Imutabilidade versus Mutabilidade - **Imutabilidade** (Redux, Immutable.js) traz previsibilidade, undo/redo e detecção de mudanças barata (referência igual = dados iguais), mas em aplicações de alto desempenho paga-se com aumento de velocidade e memória: cada mudança copia estruturas. - **Immutable.js** (List, Map, Set com tries estruturais) dá código mais limpo e arquitetura funcional, porém para datasets grandes as operações nativas (`for` loops, arrays, objetos mutáveis) são mais rápidas e menos memory hungry. - **Estratégia híbrida**: imutabilidade na camada de estado/UI (mudança de referência dispara re-render), mutabilidade disciplinada em hot paths computacionais (parsers, transformações de dados, joins em memória). - **Escrita mutável segura**: encapsule mutação em módulos pequenos (padrão RAII / scope-bound resource management — libere/feche recursos no mesmo escopo que os criou, inspirado em C++/Rust), evite mutar objetos compartilhados entre módulos. ### Técnicas funcionais com custo consciente - **Lazy evaluation**: gerecoleções sob demanda (generators/iteradores) em vez de materializar arrays gigantes. - **Tail recursion**: prefira transformar recursão em iteração (loops) — engines não garantem TCO, e stack overflow é risco real. - **Currying**: poderoso para composição, mas cria closures e funções intermediárias — evite em código de altíssima frequência. --- ## 🌐 2. JavaScript Moderno Vanilla - **let/const com escopo de bloco**, arrow functions e modules — código moderno também é código que o motor otimiza previsivelmente. - **Coleções**: `Map`/`Set`/`WeakMap`/`WeakSet` — `WeakMap`/`WeakSet` permitem GC de chaves (metadados sem vazamentos); `Map` supera objetos como dicionário em chaves dinâmicas. - **Typed Arrays** (`Int32Array`, `Float64Array`, `ArrayBuffer`): memória contígua e tipada, essencial para dados numéricos grandes, binários e transferência com Workers. - **Proxies e getters/setters**: habilitam reatividade (a base de frameworks como Svelte/Vue), mas cada acesso intercepta — não use em hot loops. - **DOM eficiente**: `querySelector`/`querySelectorAll` centralizados; **Document Fragments** para inserções em lote (uma reflow só); Shadow DOM e Web Components para encapsulamento; `<template>` para clonagem barata de markup. - **Fetch + Promises**: Promises são lazy-friendly; suporte a `AbortController` para cancelar requisições (evita trabalho de rede e parsing desnecessário). --- ## 🧩 3. Svelte e o Paradigma "Compilado para Vanilla" - Svelte compila componentes para JS vanilla imperativo — sem virtual DOM, sem runtime em produção; cada mutação de estado gera código de atualização mínima e preciso do DOM. - A lição de performance: **menos runtime = mais velocidade**. Quando uma biblioteca de framework é o gargalo, considere alternativas que empurram trabalho para o build time (compiladores, tree shaking agressivo). - Aplicações práticas (Todo, app de clima) mostram que componentes pequenos com estado local evitam re-renders em cascata. --- ## 🟩 4. Node.js sem DOM - `package.json` como centro de configuração (scripts, dependencies, type module). - **Módulos nativos**: `fs` (I/O de arquivos), `net` (sockets TCP), `http` (servidor/serviços) — nada de bibliotecas para o básico; a lib padrão é a mais rápida. - **Streams e non-blocking I/O**: nunca leia arquivos grandes inteiros na memória — pipeline com Readable/Writable/Duplex/Transform streams processa em chunks, mantenho a memória constante e o event loop livre. - **Streams customizados**: implemente `Readable`/`Writable`/`Transform` (com `highWaterMark` para backpressure) e use generators para simplificar pipelines. --- ## 📬 5. Message Passing e Protocolos (Node.js) - Comunicação local/processos: `net` com sockets de domínio Unix / TCP, IPC entre processos (cluster). - `cluster` module: multiplique processos por núcleo de CPU para saturar o hardware (Node é single-threaded por processo). - **TCP/UDP**: TCP para ordenação e confiabilidade; UDP para latência mínima sem handshake. - **HTTP/2**: multiplexing de streams numa conexão (elimina head-of-line blocking de HTTP/1.1), header compression. - **HTTP/3/QUIC**: UDP-based, 0-RTT handshake, sem TCP head-of-line blocking — a direção futura de transporte na web. --- ## 📦 6. Formatos de Dados - **JSON**: onipresente, mas verboso e com custo de encode/decode em payloads grandes. - **Formatos schema-less**: JSON, XML — autodescritivos, maiores na rede. - **MessagePack** (ex.: lib `what-the-pack`): binário compacto com pré-alocação de buffer; pode não ser menor nem mais rápido que `JSON.parse`/`stringify` nativos — sempre meça. - **Protocol Buffers (proto3)**: schema compartilhado antecipadamente, encoding muito compacto e rápido — padrão para sistemas enterprise; IDs numéricos de campo tornam a codificação e a indexação baratas. - **Formato próprio**: para casos extremos, um encoder/decoder binário customizado (ex.: schema na frente dos dados) dá o máximo controle sobre tamanho e velocidade. --- ## 👷 7. Web Workers e Paralelismo no Browser - **Dedicated Workers**: mova trabalho pesado (parsing, transformação, joins de dados, computação) para fora da main thread; comunique-se via `postMessage`. - **Structured clone tem custo real**: enviar milhares de objetos serializa/deserializa tudo — exemplo do livro: 100.000 objetos levaram de 800 ms a 1,7 s e 80–100 MB de heap. Use `Date.now()` + Profiler para visualizar o custo. - **Transferrables**: envie o `ArrayBuffer` (`postMessage(view, [view.buffer])`) — **zero cópia**; o remetente perde acesso, o receptor ganha. Para dados binários grandes é ordens de escala mais rápido. - **Shared Workers**: um worker compartilhado por múltiplas páginas/abas (ex.: cache compartilhado em memória, conexão única). - **SharedArrayBuffer + Atomics**: memória compartilhada de verdade com sincronização; exija COOP/COEP corretos. --- ## 🔁 8. Service Workers e Cache - Ciclo de vida do ServiceWorker: install → waiting → activate; intercepte requests com `fetch` event. - **Cache de páginas/templates para offline** (Cache Storage API), habilitando comportamento PWA. - **Save requests for later**: enfileire mutações offline e reproduza quando a rede voltar (padrão de filas no SW). - Cache bem-feito é a otimização mais barata: custo zero de rede e processamento nas requisições subsequentes (TTL/LRU para limitar crescimento, como no capítulo do servidor estático). --- ## 🏗️ 9. Build, Deploy e CI/CD - **Rollup**: bundler otimizado para ES modules (ESM) — tree shaking efetivo, bundles menores; use para distribuir a aplicação (server + assets) num single distributable. - Integre o build aos scripts npm (`npm run build`) e ao pipeline **CircleCI** (build → testes → checks de segurança → deploy). - Menos bytes = menos parse/compile da main thread; tree shaking é otimização de primeira ordem. --- ## ⚙️ 10. WebAssembly no Navegador - Para hot paths que mesmo JS otimizado não satisaz (geradores de códigos corretivos como Hamming, parsing pesado, matemática numérica). - Escrita direta de módulos WAT, compilação de **C/C++ para o browser** e memória compartilhada entre WASM e JavaScript (Linear Memory sobre `WebAssembly.Memory`). - Case real do livro: **SQLite compilado para WASM** rodando no navegador — banco de dados completo client-side. - Sandbox: código WASM não vazia memória entre módulos; carregue via servidor estático com MIME `application/wasm`. --- ## 🧪 Padrões de Código Recomendados ### Loop nativo em hot path (vs. abstração) ```javascript // ❌ chain de high-order functions em dados grandes: múltiplos arrays intermediários const positive = data.filter((x) => x > 0).map((x) => x * 2); // ✅ um único loop, sem alocações intermediárias const result = new Array(data.length); let count = 0; for (let i = 0; i < data.length; i++) { if (data[i] > 0) { result[count++] = data[i] * 2; } } ``` ### Transfer de binário para Workers (zero-copy) ```javascript const view = new Int32Array(1_000_000); // ... populate ... worker.postMessage(view, [view.buffer]); // transfere, não copia // ⚠️ view agora está neutered/detached no remetente ``` ### Fragmento para inserção DOM em lote ```javascript const frag = document.createDocumentFragment(); for (const item of items) { frag.appendChild(createRow(item)); } container.appendChild(frag); // um único reflow/layout ``` ### Cache LRU/TTL simples ```javascript const cache = new Map(); const TTL = 5 * 60 * 1000; function getCached(key) { const hit = cache.get(key); if (!hit) return null; if (Date.now() - hit.ts > TTL) { cache.delete(key); // evita crescimento infinito return null; } return hit.value; } ``` --- ## ⚠️ Pegadinhas - **GC non-determinístico**: alocação massiva em hot paths (cada evento do usuário gerando objetos) causa GC pauses difíceis de prever; reduza taxa de alocação, não confie em "o GC resolve". - **Layout thrashing / forced synchronous layout**: intercalar leitura e escrita de propriedades de layout (`offsetHeight` ↔ `style.height`) força reflow a cada iteração — separe leituras das escritas (ou use requestAnimationFrame batching). - **postMessage com objetos gigantes**: structured clone duplica memória e congela a thread — transfira `ArrayBuffer`s ou use `SharedArrayBuffer`. - **Benchmarks enganosos**: um único motor, código morto eliminado ou código extrano enviesam resultados; teste em vários navegadores e certifique-se de consumir os resultados. - **Dependências em runtime**: bibliotecas de imutabilidade/functional helpers em datasets grandes custam mais que nativo — "tudo é trade-off". --- ## 🔗 Integração com Outras Skills - [latency-engineering](../../engineering-practices/latency-engineering/SKILL.md): leis da latência, tail latency e eliminação de trabalho desnecessário aplicadas à web. - [code-optimizer](../../roles/code-optimizer/SKILL.md): hierarquia algoritmo → estrutura → runtime → paralelismo aplicada a aplicações JS. - [webassembly](../webassembly/SKILL.md): Wasm como destino definitivo para hot paths (Emscripten, wasm-pack, SharedArrayBuffer/Atomics). - [framework-react](../../framework/framework-react/SKILL.md): imutabilidade de estado, memoization e re-renders no ecossistema React. - [framework-vue](../../framework/framework-vue/SKILL.md): reatividade baseada em getters/setters e Proxies (mesmos fundamentos do capítulo vanilla). - [frontend-developer](../../roles/frontend-developer/SKILL.md): integração de otimizações de performance no ciclo de construção da UI.