The patched version of #Mutter + #GNOME Shell I've been running for the last few days, while profiling with @YaLTeR, is crazy fast.
This is the first time in 13 years that my GNOME Shell isn't slowing down after a few hours/days. Even without triple-buffering.
It is so smooth, I can't stop moving windows around just to savor how unreal it feels. Turns out I never experienced 60 fps (with & without #Wayland) in GNOME in my life, until this week.
@nekohayo This sounds great, do you have any idea when this patch will be released (or is it already ? I have no clue how these things work but you make it seem awesome!)
@KeyLawd It will be in 46 for sure, and I am waiting for definite proof that it would be backported to 45.2 and 44.7 due in December; I'm not 110% sure yet until I see it landing in those stable series' branches, but I'd be a bit surprised if it doesn't happen…
@razze If my "infamously old" desktop workstation machine can now run butter-smooth for extended periods of time, I have no doubts that this (and perhaps other potential optimizations we can find) would have positive impacts on embedded/mobile devices, and on recent overpowered desktop machines as well (where the effects have been more subtle, but still present and noticeable when you pay attention to them like I do).
Ironically this is one rare case where it wasn't profiled with @hergertme's sysprof, but Tracy (with GJS instrumented for it by @YaLTeR), and in big part due to profiling on my "middle-schooler" computer that @alatiera loves to hate (I think I should rename it from "Kusanagi" to "KissingerKiller" now).
I'll never stop saying this: code/compile on "brand new" computers, test on old computers and optimize for those; your "brand new" computer will benefit from it.
@nekohayo@YaLTeR@alatiera in many cases yes, but in a whopping number of tight loop cases we’re all running shitty code because we’re trying to keep old x86_64 alive instead of requiring new instructions. Few things end up using the gcc dispatch functions per sub-arch.
@hergertme@YaLTeR@alatiera I guess one can eventually hit physical limits someday, but outside of video codecs, in my day-to-day userspace experience, I think I can count on the fingers of one hand the number of times in the last 20 years where I've seen a performance issue being due to hardware limitations rather than software doing excess work (or doing the wrong thing at the wrong time) 🧐️
@nekohayo@YaLTeR@alatiera There are certainly different classes of issues. But if you can tighten up a lot of code to use fewer CPU cycles across the system, there are generally energy savings to be had.
@nekohayo@YaLTeR 13 years isn't surprising, it reminds me of Bryan Cantrill seeing Gnome 2 (on Solaris) do a whole bunch of calls in his dtrace talk+demo from 2007: https://www.youtube.com/watch?v=TgmA48fILq8 (Relevant part after 00:20:00)
@matzipan The non-spoiler version is, stop leaking/duplicating some signals, stop doing extra work with icons, and possibly more to come if we I can encounter remaining problems… I'm still in shock at how I am not encountering any more problems so far.
Add comment