useDragLeave performance issues

[raineorshine]

As reported:

1. Initialization of Thoughts

• Details: Approximately 400 Thought components are rendered, with sub-Thoughts randomly assigned to a subset of parent Thoughts.
• Impact: The large volume of components contributes to significant performance challenges, particularly during rendering and user interactions.

2. Collapsing via Thought Body

• Details: Collapsing a parent Thought by clicking on its body triggers the useDragLeave hook for all associated sub-Thought components.
• Impact: This causes unnecessary performance overhead, especially when working with deeply nested Thoughts.

collapsing-issue.mp4

3. Collapsing via Arrow Icon

• Details: Collapsing a parent Thought by clicking the arrow icon triggers the useDragLeave hook for all 400 Thought components, not just the associated sub-Thoughts.
• Impact: This behavior results in severe performance degradation, leading to slow and unresponsive interactions.

4. Rendering Performance on Page Refresh

• Details: Refreshing the page to re-render all Thoughts is significantly slow.
• Cause: The useDragLeave hook is unnecessarily triggered across all 400 components during the rendering process.
• Impact: This behavior leads to delayed initial page loads and poor user experience.

refreshing-issue.mp4

5. Performance Metrics
   Here are the observed loading times for both page refresh and collapsing Thoughts via the arrow icon, measured at different scales:

• Page Refresh Times:
  • 100 Thoughts: 120 ms
  • 200 Thoughts: 649 ms
  • 300 Thoughts: 8,220 ms
  • 400 Thoughts: 19,554 ms
• Collapse Times via Arrow Icon:
  • 100 Thoughts: 357 ms
  • 200 Thoughts: 2,025 ms
  • 300 Thoughts: 5,020 ms
  • 400 Thoughts: 12,621 ms

[raineorshine]

• 400 thoughts - Please provide the exact sample data you are using so that we can document and reproduce the issue. The export feature allows you to easily export the current thoughtspace. However, I would suggest using non-empty thoughts since empty thoughts don't re-import very well.
• Page Refresh Times - What is the 120ms measuring? i.e. When does the timer start/end? We will need this to be able to deterministically reproduce the test case across machines and across developers. Think of your work as surfacing existing issues that need to be documented and formalized for us to establish baselines and do scientific analysis on.
  • Does it include load time of static assets? We may want to separate the initial load from the initial render cycle so that we can measure and optimize them separately.
• Collapse Times - Same here, though this is more straightforward since we don't have to worry about other contributions to startup time.