Guide de performance

Le rendu rapide commence avant Canvas2D. Conservez les données en colonnes, transférez-les une seule fois, évitez le décodage sur le thread principal et laissez le graphique ne rendre que le détail visible à l’écran.

LOD signifie niveau de détail : le moteur utilise une représentation de la taille de l’écran des grandes données et révèle des détails plus fins lorsque l’utilisateur effectue un zoom. Commencez par la sélection automatique des workers et la stratégie LOD par défaut, puis mesurez la charge réelle. Utilisez le laboratoire d’étalonnage LOD uniquement avant de modifier la densité, le ratio de rebase ou la quantification.

Pipeline de chargement recommandé

1. Afficher un petit aperçu conservant les extrêmes lorsque la latence de la première image est critique.
2. Démarrer la récupération réseau et le décodage dans un worker de données dédié.
3. Lire uniquement les colonnes et plages requises depuis un format en colonnes.
4. Valider les longueurs alignées, X ordonné fini, les unités et les gaps déclarés.
5. Transférer une fois les colonnes typées vers le moteur de rendu du graphique.
6. Terminer le worker de données après le transfert afin qu’il ne conserve pas une autre copie.

Pour les lectures HTTP par plage, vérifier que l’hôte statique prend en charge les plages d’octets et que la mise en cache intermédiaire les conserve; un repli correct en téléchargement complet peut néanmoins rester trop coûteux pour les visiteurs mobiles.

Conservez le bundle initial compact

• Importez dynamiquement les décodeurs de données lourdes et les démos optionnelles.
• Montez uniquement le graphique actuellement visible ou sélectionné.
• N’envoyez pas de jeux de données de démonstration de plusieurs millions de lignes vers une page d’accueil uniquement pour prouver que le moteur de rendu peut les accepter.
• Tenez les catalogues de thèmes et les exemples secondaires en dehors d’un chemin protégé de première image.
• Privilégiez des exemples sélectionnés ou adaptatifs sur les appareils contraints et liez-les à un poste de travail complet.

Choisir le mode worker

Utilisez renderMode: "auto" dans les applications générales et mesurez le mode résolu. Le mode thread principal est utile pour les tests et les petits graphiques statiques, mais de grands ensembles de données interactifs devraient normalement s’exécuter dans un worker.

Ajuster la présentation des lignes selon la charge

La plupart des applications n’ont pas besoin de valeurs LOD personnalisées.

lod.density est le contrôle principal de fidélité/charge. Commencez à 0.75. Augmentez-le lorsque le détail local est visiblement insuffisant et que le temps de frame reste confortable. Réduisez-le pour les plages remplies en plusieurs passes, les forts rapports pixel/appareil ou les navigateurs où le coût du remplissage Canvas2D domine.

La finesse de la représentation dépend de rebaseRatio et quantizationStep, pas seulement de la densité. Des valeurs plus fines réduisent les changements de texture individuels mais augmentent la fréquence des requêtes de hiérarchie. Ajustez lors de gestes de zoom réels et comparez le temps de frame en régime permanent, les visites de requêtes, les sommets de présentation et la stabilité visuelle.

Utilisez setStatsCallback temporairement pendant le développement :

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

Désactivez le rappel en production lorsque l’application ne consomme pas de télémétrie.

Regrouper les mises à jour

• Utilisez les API en masse basées sur les tableaux typés lorsque tout le lot existe déjà.
• Utilisez batch() pour plusieurs modifications impératives synchrones causées par une seule action d’interface utilisateur.
• Évitez de construire des tableaux ou de formater des chaînes à l’intérieur des callbacks exécutés par image.
• Ajoutez un délai (debounce) aux reconstructions côté application pour les flux et ignorez les résultats asynchrones obsolètes.

Les constructeurs LOD en streaming du graphique achèvent le travail basé sur des instantanés pendant que de nouveaux échantillons arrivent et conservent les niveaux complétés utilisables jusqu’à ce qu’un remplacement soit prêt. Ne réinitialisez pas le streaming ni ne remplacez l’ensemble du jeu de données pour chaque observation ; ajoutez plutôt via les streaming APIs. Le streaming de lignes met à jour les bornes de façon incrémentale plutôt que de rescanner le tampon complet à chaque ajout.

Les adaptateurs de framework ne collectent des statistiques que tant qu’un rappel ou un écouteur actif peut les recevoir. Vue cesse la collecte après qu’un unique écouteur .once a été consommé ; Angular s’arrête également lorsque les subscriptions sont terminées ou que la sortie se ferme. Supprimez les écouteurs de télémétrie lorsque l’application n’utilise plus leurs mesures.

Conserver la signification des données

La réduction de performance doit conserver les extrema et les véritables intervalles manquants. Ne jamais pré-moyenner une enveloppe de plage, relier des intervalles manquants ou sous-échantillonner indépendamment chaque entrée d’aire empilée. Pour les OHLCV, agrégez open-first, high-maximum, low-minimum, close-last et le volume sommés sur les observations réelles.