Guia de desempenho

A renderização rápida começa antes do Canvas2D. Mantenha os dados colunares, transfira-os uma vez, evite decodificação no thread principal e permita que o gráfico renderize apenas a representação visível.

Comece com a seleção automática de worker e a política LOD predefinida, depois meça a carga real. Use o LOD calibration lab antes de alterar densidade, razão de rebase ou quantização.

Pipeline de carregamento recomendado

1. Mostre uma pré-visualização pequena que preserve extremos quando a latência do primeiro frame for importante.
2. Inicie a obtenção pela rede e a decodificação num worker de dados dedicado.
3. Leia apenas as colunas e intervalos necessários de um formato columnar.
4. Valide comprimentos alinhados, X ordenado e finito, unidades e lacunas declaradas.
5. Transfira colunas tipadas para o renderizador do gráfico uma vez.
6. Termine o worker de dados após a transferência para que não retenha outra cópia.

Para leituras HTTP por intervalos, assegure que o anfitrião estático suporta byte ranges e que o cache intermédio os preserva. Um fallback de download completo correto pode ainda ser demasiado dispendioso para visitantes móveis.

Mantenha o bundle inicial pequeno

• Importe dinamicamente decodificadores de dados pesados e demos opcionais.
• Monte apenas o gráfico atualmente visível ou selecionado.
• Não envie dados de demonstração com milhões de linhas para uma página de entrada apenas para provar que o renderizador os aceita.
• Mantenha catálogos de temas e exemplos secundários fora de um caminho protegido do primeiro frame.
• Prefira exemplos curados ou adaptativos em dispositivos limitados e ligue para um workbench completo.

Escolher modo de worker

Use renderMode: "auto" em aplicações gerais e meça o modo resolvido. O modo thread principal é útil para testes e gráficos estáticos pequenos, mas conjuntos de dados interactivos grandes devem normalmente correr num worker.

Ajuste a apresentação de linhas pela carga de trabalho

lod.density é o controlo primário fidelity/work. Comece em 0.75. Aumente-o quando o detalhe local estiver visivelmente insuficiente e o tempo de frame permanecer confortável. Diminua-o para intervalos preenchidos em múltiplas passagens, altas razões de píxeis por dispositivo, ou navegadores onde o custo de fill do Canvas2D domina.

A suavidade da representação depende de rebaseRatio e quantizationStep, não apenas da densidade. Valores mais finos reduzem alterações individuais de textura mas tornam as pesquisas na hierarquia mais frequentes. Ajuste com gestos reais de zoom e compare o tempo de frame em estado estacionário, visitas a queries, vértices de apresentação e estabilidade visual.

Use setStatsCallback temporariamente durante o desenvolvimento:

chart.setStatsCallback((stats) => {
  console.table({
    frame: stats.frameTime,
    mode: stats.presentationMode,
    vertices: stats.presentationVertices,
    visits: stats.presentationQueryVisits,
    ready: stats.lodReady,
  });
}, { intervalMs: 250 });

Desative o callback em produção quando a aplicação não consumir telemetria.

Agrupar atualizações

• Use APIs de typed-array em lote quando um batch completo já existir.
• Use batch() para várias alterações imperativas síncronas causadas por uma ação de UI.
• Evite construir arrays ou formatar strings dentro de callbacks por frame.
• Debounce reconstruções de streaming do lado da aplicação e ignore resultados assíncronos obsoletos.

Preserve o significado dos dados

A redução de desempenho deve reter extremos e lacunas reais. Nunca pré-media uma envelope de intervalo, conecte intervalos em falta, ou subamostre cada entrada de área empilhada independentemente. Para OHLCV, agregue open-first, high-maximum, low-minimum, close-last e volume somado sobre observações reais.