-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Make Html (VNode) cheap to clone #3431
Conversation
Size Comparison
|
Benchmark - SSRYew Master
Pull Request
|
Visit the preview URL for this PR (updated for commit 594e3d4): https://yew-rs-api--pr3431-html-cheap-to-clone-fnap4qt0.web.app (expires Fri, 03 Nov 2023 13:58:49 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 |
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 think the current benchmark result does not reflect improvements in this pull request.
Would it be possible to add a benchmark that demonstrates the performance difference before and after this pull request?
Yes 100% agreed..... just need to figure out how xD I think a classic benchmark with criterion on different kind of VNode will work best |
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.
Nothing jumps out by skimming through the code. I agree with futursolo that it needs to benchmarked though
There is a new & shiny library 🙌 https://hachyderm.io/@nikolai/111179659061831881 |
It doesn't run on WASM: nvzqz/divan#3 |
I'm struggling with this workflow xD @futursolo maybe you can help me? I think the commit befcaa2 would have work but the post thing doesn't start. I believe it is because the workflow does not exist yet on the main branch. So I changed it to use 2 steps instead of 2 workflows (e0711b1) and now I have a 403.
(From the doc) |
I think the original approach should work. GitHub Actions no longer allows The only way to figure out if it works is to merge the benchmark and create an additional pull request to test. |
@@ -16,25 +17,27 @@ use crate::AttrValue; | |||
#[must_use = "html does not do anything unless returned to Yew for rendering."] | |||
pub enum VNode { |
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.
May I ask why option 1 is selected by this pull request?
I feel other options would produce better public APIs.
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 remember I couldn't do option 2. I got lost in the change and didn't manage to make it work.
Option 3 is actually used here. It's a mix of option 1 and option 3. In some cases, cloning a single object was cheaper so I added Rc in places it wasn't strictly necessary. (related to #3431 (comment))
Now if I recall I think there wasn't a strong interest of going for one or the other option so I did go wherever it worked.
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 think in the end we need both option 1 and 3. Because option 1 is better for the user as they will pass html nodes (Html/VNode) through props so this need to be fast. But option 3 is important for the internals of Yew. Huh but it's really just theory.
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.
Users may also want to pass VChild/VList directly for a better API to components (but those are already cheap to clone, so option 3 is already somewhat implemented)
Ok I have put back the 2 workflows files and I think it's ready to merge. I think this PR is very important and we should be absolutely sure that the implementation is right as we want it to be. So feel free to take your time to review again @hamza1311 @futursolo maybe others will have opinion on this. From my point of view I don't see much differences between the different options but I do think having VNode (or Html) cheap-to-clone is a MUST have. |
Out of curiosity: if VList is already cheap to clone (ImplicitClone) why is VNode::VList with Rc? |
I think it was cheaper to clone 1 Rc instead of multiple ones? At least that's my theory. But let's see what the benchmark says... With Rc wrapping VList:
Without Rc wrapping VList:
|
@cecton the best way to ensure the workflow works is rip it out of this PR and make another one with the benchmarks that's merged before this one. Then you can rebase this one and get the benchmark results |
I don't know why I didn't think of that earlier xD |
Benchmark - coreYew Master
Pull Request" >> comment.txt
|
@ everyone dont hesitate to push commits on the PR to test things out! |
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'm fine with merging it. There is more indirection in reading the data, not sure how that affects things. Cheap cloning is very important for Html as it's everywhere and cloned most of the time it's used
The benchmarks show a big improvement and no one has raised any issues with the implementation so I'm going to go ahead and merge this. If anything comes up, it can always be addressed later.
Description
I tried to do this change a few times this year but couldn't make it works.
There was always something blocking me somewhere in the code that was just too
complicated to solve. But now, it seems that Yew has evolved so much that this
change is now easy to do! [edit: actually it wasn't 😓] I'm really happy about it.
I'm not gonna explain the whole thing again. Please refer to the discussion.
Related to #3022
Checklist