Initial performance observations #148
Replies: 3 comments
-
Thank you for checking out Cushy. Initially, I was simply going to reply asking you whether you were testing the main branch vs 0.2, what OS, what computer/GPU, whether wgpu is using Vulkan vs OpenGL, etc. On my limited test hardware, in debug mode it maybe is a little choppy, but it was still smooth. Neither of my test machines is newer than 4 years and were medium-of-the-line builds at the time. However, I also knew of a couple of things that aren't being optimized fully. Specifically, But, then I realized I'm caching it, and so I was wondering if for some reason scrolling was invalidating the cache. Turns out it was (5e266f1). After this change, text layout isn't performed as the text is scrolled, which should make this example perform well for you. If not, more information about your configuration would be helpful! To answer your question more generally, I think that a lot of the easy optimization work has been done for Cushy already, but individual widgets may have issues (like the one I just fixed). Reporting any lackluster performance with reproducible examples will go a long way in allowing me to profile and hopefully optimize any issues. |
Beta Was this translation helpful? Give feedback.
-
Great, I can confirm that after the change the example is very smooth for me in release mode. Thanks for the quick fix and the background information! I think my impression was also affected by first having tried many examples in debug mode, which didn't quite feel like 144 fps. But considering that cushy is essentially "pure Rust", I guess it is expected that they aren't super smooth in debug and it probably also doesn't tell much about release performance. Regarding But regarding the general context: My system is an Ubuntu 22.04, with a GeForce GTX 980, and the Vulkan backend. |
Beta Was this translation helpful? Give feedback.
-
Glad to hear that it helped!
Cushy really uses Rust as much as possible, which means that nearly everything being in debug mode is really hard to be performant. Still, comparing some of Cushy's examples to other frameworks, I feel like Cushy in debug mode performs quite well relatively speaking. In general, I've seen people try to alleviate these problems by having Cargo optimize dependencies, while leaving the crate you're working on unoptimized. For example: [profile.dev.package."*"]
opt-level = 2 Since the dependencies aren't being rebuilt constantly, spending extra time on optimizing them takes longer the first time you build, but incremental builds will remain fast. That being said, if you ran the example in the Cushy repository, this patch is already in the Cargo.toml. The last random comment I have is that I believe the GTX 980 is one of the earliest card architectures that wgpu fully supports on all platforms. I'm glad to hear that Cushy seems to be at least functioning on it! I've tested with modern-ish integrated graphics, but I'm not sure I had heard of Cushy being used on this early of a dedicated card yet. I tend to write a lot, so don't feel required to reply. I just like trying to be helpful :) |
Beta Was this translation helpful? Give feedback.
-
First of all, thanks for your work, this looks pretty intriguing!
I'm not sure if it makes sense to talk about performance at this early stage, but just to clarify it this is known/expected: Overall the examples feel a bit jerky in terms of rendering performance. Obviously there is a difference between debug and release modes, but for instance the
scroll
example seems to have rather low fps even in release mode. I haven't actually measured anything yet, so that's just an impression.Is this some kind of inherent overhead in the reactive system or simply just a lack of certain optimizations that should be fixable in general?
Beta Was this translation helpful? Give feedback.
All reactions