fix: 912-helpers-disposal-issue #913
Open
+98
−55
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
✅ Deploy Preview for tresjs-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
alvarosabu
added
the
p4-important-bug
commit: |
Guessing this is a typo. Should be |
Yes, is 3,929 MB |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
requestAnimationFrameinstead of interval for more accurate results across multiple devices running the testdisposeObject3Dmethod to removedeletes. Improved different type of object disposal (BufferGeometries, Scenes, Lights etc)Closes #912
Tests
Test were done using
MemoryTresObjects.vuewith 2000 objects and 400 TresCanvas instances (instead of 1000 since no-disposal tests were hanging the browser at 500)Browser: Chrome incognito mode.
Performance
No Disposal
Comments: We can see how the JS Heap grows on an upward trend that reaches almost 4 GB. This is the baseline
Current disposal (using delete)
Comments:
New disposal
JS Heap is now much more stable (7.9MB - 232MB vs previous 7.7MB - 503MB)
The sawtooth pattern in the heap graph is more regular and controlled
The baseline doesn't show the same concerning upward trend
Memory spikes are smaller and more consistent
Memory allocation timeline
No disposal
Browser crashed.
Current disposal
New Disposal
Comments: in the second screenshot, you will notice if compared with current implementation the presence of the properties of BoxGeometry, that indicates that the objects aren't being fully garbage collected - their internal methods and properties are still being retained in memory. This is different from what we'd expect in a fully disposed object, where these internal details should not be visible anymore.
Summary
Performance Metrics
Memory Allocation
Key Observations
Performance: New implementation takes ~32% longer but shows more stable memory patterns
Memory Peak: New implementation reduces maximum memory spike by 271MB
Memory Distribution: New implementation shows better percentage distributions across all categories
Resource Management: Better cleanup of WebGL resources despite higher total selected size
Memory Tracking: More detailed memory tracking visible in new implementation (BoxGeometry properties visible)