Performance Optimization

[wang1212]

In the process of upgrading G from v4 to v6, the underlying layer of G has been refactored a lot, from a single engine that only provides basic rendering capabilities to a plug-in engine, enriching a lot of ecological capabilities.

Unfortunately, performance issues were not paid close attention to during this process, resulting in a serious regression of performance benchmarks. So far, we have made a lot of efforts to optimize performance, but the results are still not ideal. The root cause is that our current strategy is relatively conservative. If we want to really improve performance, we need to make some adjustments to the current architecture. Considering the developer experience and maintenance costs, this is based on the premise that there are no major changes to the API.

Related performance issues:

• v5/v6 版本滚动性能下降明显 #1712

Here are some to-do items:

• Simplify event system design
  • Cancel unnecessary event bubbling perf: optimize element event distribution and attribute update process #1944
  • Refactor the event system to simplify logic complexity and event flow
• Simplify the element picking process in interactive events and remove rbush dependency perf: remove rBush logic from element picking mechanism #2031
• Simplify hook design (redundant design leads to inconsistent plugin implementation, which increases complexity).
  • Simple and clear rendering process stage, commit to render
• Basic graphic elements
  • Measurements of text elements perf: use charWidthCache to improve performance by 1.5% #1978
• Benchmarks and Statistics
  • Comparison of performance benchmarks with other engines feat(benchmark): Add performance test suite and analysis panel #1987
  • Performance Testing in CI
  • Runtime performance statistics

Completed optimization (PRs):

• perf: optimize performance #1789
• perf: optimize large image rendering performance #1798
• perf: optimize canvas renderer performance #1810
• perf: use map instead of RefCountCache to avoid memory leaks #1939
• perf: discard animation when target is destroyed to avoid memory leaks  #1940
• perf: optimize element event distribution and attribute update process #1944
• perf: use charWidthCache to improve performance by 1.5% #1978
• feat(benchmark): Add performance test suite and analysis panel #1987
• perf: element event batch triggering #2005
• perf: remove rBush logic from element picking mechanism #2031
• perf: batch update attributes #2001

Reference performance benchmarks:

• https://benchmarks.slaylines.io/

Case	Before	After

[github-actions[bot]]

@wang1212 Hello! Here is an automated response to your question:

---

🚀 Performance Optimization in G v6 – Next Steps

Thank you for the detailed summary of the performance challenges and ongoing efforts in upgrading G from v4 to v6. Here are targeted recommendations and clarifications for each optimization area, based on current best practices and official documentation:

---

1️⃣ Event System Design

Current Actions:

• Unnecessary event bubbling has been removed.
• Plans to refactor the event system for reduced logic complexity.

Recommendations:

• Minimize Event Propagation: Continue eliminating redundant event flows and bubbling to reduce overhead.
• Lean Listener Registration: Use direct event listeners on required nodes only. Avoid broad registrations at the root unless necessary.
• Custom Events: When dispatching custom events, prefer lightweight payloads and avoid deep copying of event objects.

Example: Direct Event Handling

circle.addEventListener('mouseenter', () => {
  circle.attr('fill', '#2FC25B');
});
circle.addEventListener('mouseleave', () => {
  circle.attr('fill', '#1890FF');
});

---

2️⃣ Element Picking Process & Dependency Simplification

Current Actions:

• Element picking optimized, rbush dependency removed.

Recommendations:

• Use Native Selectors: Leverage CSS selector APIs (querySelector, querySelectorAll) for efficient element retrieval.
• Disable Hit-Testing Where Unneeded: For static/non-interactive elements, set pointerEvents: 'none' to skip picking logic.
• Layer Separation: Isolate static and dynamic content for more efficient re-rendering and picking.

Example: Query Elements by Attribute

const moons = solarSystem.querySelectorAll('[r=25]'); // Finds all elements with r=25

---

3️⃣ Hook Design for Plugin Clarity

Current Actions:

• Recognized redundant hook designs causing plugin inconsistencies.

Recommendations:

• Single Responsibility Hooks: Define hooks for specific rendering stages (e.g., init, beforeRender, afterRender).
• Clear Lifecycle Events: Ensure plugin hooks align with canvas lifecycle events (e.g., mounted, unmounted).
• Simplified API: Aim for concise hook interfaces to ease plugin implementation and maintenance.

Example: Rendering Service Hook

renderingService.hooks.init.tap('PluginTag', () => {
  // Initialization code
});

---

4️⃣ Benchmarks & Runtime Statistics

Current Actions:

• Benchmarks compared with other engines.
• Plans for CI-based performance testing and runtime stats.

Recommendations:

• Integrate Stats.js: Automatically update runtime stats after each render to detect regressions.
• Automate in CI: Incorporate performance test scripts into CI pipelines for early detection.
• Display Key Metrics: Log FPS, memory usage, and render times for continuous monitoring.

Example: Stats Integration

canvas.addEventListener(CanvasEvent.AFTER_RENDER, () => {
  stats.update();
});

---

📊 Reference Benchmarks

To track progress, continue updating and comparing with the official benchmarks.

---

✅ Summary Action Items

• Event System: Refactor for minimal propagation and direct listeners.
• Element Picking: Use selectors; disable hit-testing for static elements.
• Hooks: Streamline hook interfaces for plugins.
• Benchmarks: Integrate stats and automate CI checks.

If you need further guidance or real code samples for any item, please specify your scenario. Let's keep momentum on these improvements!

---

---

This is an automated response generated by AI. If you have any questions, our team will follow up as soon as possible.