-
-
Notifications
You must be signed in to change notification settings - Fork 22k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize SceneTreeEditor::_update_node_tooltip()
#97777
Conversation
fca248d
to
c1e507d
Compare
restore the original |
c1e507d
to
0e3c103
Compare
0e3c103
to
95894d3
Compare
tooltip += "\n"; | ||
tooltip += TTR("Inherits:"); | ||
tooltip += " "; | ||
tooltip += p_node->get_scene_inherited_state()->get_path(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not for now, but this makes me think we should have some vararg StringBuilder method for appending multiple strings at once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't measure performance, but functionally it works correctly.
AFAIK using LocalVector in StringBuffer was an already planned optimization
055cb6e
to
3f916e2
Compare
Seems no more review, squash commits and rebase against master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! The timing is wonderful too, I was just noticing the cost of StringBuilder in the ShaderCompiler. I tested this locally and confirmed that it already helps there (without even taking advantage of using a static version of StringBuilder).
In follow up PRs we should be using a static StringBuilder in more places
Have you had a chance to look at the improvements you mentioned in #77158 (comment)? I ran some quick tests this weekend and compared the performance of #77158 against this PR (using a String internally) when compiling shaders and #77158 still seems to be faster by a small margin |
Co-authored-by: Tomek <kobewi4e@gmail.com>
@clayjohn Can you share your test project? The one I used above cannot show difference anymore (some The small difference you measured should probably be Small String Optimization, I'm seeking to introduce that to |
3f916e2
to
4fbaceb
Compare
Co-authored-by: A Thousand Ships <96648715+AThousandShips@users.noreply.github.com>
@YYF233333 Here is my test scene. It waits one second, then compiles 300 shaders. It prints the time each frame so you can get a rough sense of how long the overall compilation took. To get the timing of StringBuilder, I ran this demo with a sampling profiler attached so I could see the cost of StringBuilder in particular. |
I have submitted #100295 to separately merge buffer changes in If you disagree, feel free to merge this PR and close #100295, as it does not add any additional functionality not also added here. |
Close this in favour of #100295. |
split to 2 commit to make review easier.
Make
SceneTreeEditor::_update_node_tooltip()
reuse the string build buffer instead of alloc buffer/tmp string everytime.1st commit: make
StringBuilder
suitable for multi time use by reusing the buffer inas_string()
method.2nd commit: use a static
StringBuilder
for string concat.performance:
bench with ManyNodes.zip, test time to open
ManyNodes.tscn
(100k nodes).Master branch: (about 9.5s)
This PR: (about 9.0s)
This PR without changes applied to
StringBuilder
: (about 9.5s)