Ubuntu 20.04 LTS To Optimize GNOME For Fast/Modern PCs, Ubuntu 20.10 For Slow/Older PCs

[GrayShade]

Not sure how they do it, but Intel's Clear Linux it's on top of most benchmarks and not like Canonical, who want to separate users on LTSs and ordinary Ubuntu releases.

Intel uses more aggressive optimization options and function/library multi-versioning, as opposed to most distros that compile for CPUs from the 2000s (for 64-bit) or 1990s (on 32-bit). They also work on improvements for the kernel and other software, and while their patches might hit upstream, that's going to take more time. And I think they might be switching to newer compiler versions faster than others.

[finalzone]

Meanwhile, I can reassure you that i5-8400 with GNOME is laggy even when no applications are running. Animations drop frames all the time, which is distracting and looks bad.

Which distribution was used to run Gnome Shell? Switch to another major one and see the same specification will have no problem running it. Another possibility is your test was done through virtualization using LLVMpipe as a fallback. The two laptops I mentioned earlier i.e. 2007 Sony VIAO and 2005 LG Tabet PC much older than your I5-8400 powered device have no problem on Fedora Workstation.
I am writing from the soon to be launched Fedora 31Workstation based running on HP Envy x360 Ryzen 2500u at 1.3 GHz frequency according to lscpu command. Therefore the claim that Gnome Shell needs at least 5GHz cpu is invalid.

[Britoid]

The problem with every FOSS projects is that everyone feels entitled to flame a technical opinion, no matter how fucking nonfactual (or sometimes nonsensical) it is. How many times lots of knowledgeable people have shared here that GJS isn't a problem (or at least an important one). You would however have tons of people shitposting here that the problem with Gnome is that it uses JS, day in, day out. Gnome developers (or systemd developers, or whatever) could have a friggin online PhD program about the shortcomings of their software. People would still complaint in the most unfounded ways. I rather read a Windows user hating on windows just calling it crap that a Linux user hating on some component of his OS because the problem is that the reference counting of the symbols used to translate the move instructions to the GPU via shared objects written in OCaml is stupid (or some other nonsensical comment like that).

DVG seems to be doing a great work and I am happy for it. But if you ever developed even a 300 lines python script, just reading at the Gitlab's discussion you can tell the guy is difficult to work with. Even more, the tone of his blog post, although incredibly interesting (and educational), is a really big PR stunt, written from the perspective that the only improvements for Gnome were the ones Canonical (i.e. him) contributed. Gnome developers had already started taking performance as a priority since, I think, 3.30. There were several articles here at Phoronix about that.

I hope the guy can become a better fit for the community, then we'll all benefit even more. And I also hope that he (or Georges, or whoever) manage to fix the idling bugs soon.

Look clearly GNOME devs are lying when they say Javascript isn't the problem for GNOMEs performance issues and people who don't use GNOME Shell know better, duh.

[finalzone]

finalzone It’s just another KDE user throwing a tantrum. Let him sit it out. Eventually he will reread the blog and actually understand it.

Hopefully.

[Britoid]

That depends entirely on how you see Ubuntu:

• Modern desktop OS
• Server OS
• IoT and embedded OS

I'd argue that most people on Phoronix would fall into the first category. The latter two have much better and faster options than Ubuntu nowadays so I guess it's the right move by Canonical to optimize for fast machines.


Daniel's work is a fucking godsend to Mutter and honestly the smug greybeards at Gnome just don't deserve Canonical's improvements.

Oh wow, someone who's paid full time to work on GNOME Shell performance patches is able to create them at a faster rate compared to people who volunteer and have to maintain the entire shell, not just parts responsible for rendering.

GNOME Shell only has a couple of full-time maintainers.

[Britoid]

Vanvugt repeated what other GNOME devs have said for years. Javascript is not a problem. Threading is not a solution.

I'd argue KMS and input threading should be something to aim for in the future because it helps prevent the compositor from delaying input and the screen updating. But it would of just put a rubber band on the performance problems that have or are being fixed.

[Guest]

Which distribution was used to run Gnome Shell? Switch to another major one and see the same specification will have no problem running it. Another possibility is your test was done through virtualization using LLVMpipe as a fallback. The two laptops I mentioned earlier i.e. 2007 Sony VIAO and 2005 LG Tabet PC much older than your I5-8400 powered device have no problem on Fedora Workstation.
I am writing from the soon to be launched Fedora 31Workstation based running on HP Envy x360 Ryzen 2500u at 1.3 GHz frequency according to lscpu command. Therefore the claim that Gnome Shell needs at least 5GHz cpu is invalid.

I'm talking about a test I've done a while ago with Ubuntu running on bare metal, so I'm pretty sure it was accelerated. It dropped frames even with no software running, so I'd say you probably need that 5 GHz CPU to have a chance of seeing animations play the way they were intended to be, and not look like a skippy mess.

[GrayShade]

Guest You didn’t test 3.34/35 and you clearly didn’t read vanvugt’s blog.

Of course, Guest is wrong since even Daniel's blog says that Gnome has a lot of issues that make it drop frames regardless of how fast your hardware is. Not even 5 GHz will save you from those.

I'm using Gnome 3.34. It's much better than a couple of years ago, mostly thanks to Daniel's work. But then again, if your WM burns 80% CPU just because you're moving a window, calls fsync() on the main thread, or can't draw the mouse cursor when other programs use CPU, people will complain.

The compositor is basically a (soft) real-time app, and should be written as such. It should avoid GC pauses and disk access on its main thread. It shouldn't lag for a couple of seconds when I move the mouse cursor over the clock area. And, of course, it shouldn't crash and lose my session because my "XBill" extension crashed.

[finalzone]

I'm talking about a test I've done a while ago with Ubuntu running on bare metal, so I'm pretty sure it was accelerated. It dropped frames even with no software running, so I'd say you probably need that 5 GHz CPU to have a chance of seeing animations play the way they were intended to be, and not look like a skippy mess.

It seems an issue specific to the distribution i.e. Ubuntu in this case because the same desktop environment Gnome Shell 3.3 running on Fedora 31 powered HP Envy x360 Ryzen 2500u runs smooth without requiring 5 GHz as a minimum. Even the previous Gnome Shell 3.32 on Fedora 30 runs smoothly.

Edit: Test the same hardware with a livemedia Fedora Workstation 30 or 31 and see if you encounter the same problem.

[leech]

It seems an issue specific to the distribution i.e. Ubuntu in this case because the same desktop environment Gnome Shell 3.3 running on Fedora 31 powered HP Envy x360 Ryzen 2500u runs smooth without requiring 5 GHz as a minimum. Even the previous Gnome Shell 3.32 on Fedora 30 runs smoothly.

Edit: Test the same hardware with a livemedia Fedora Workstation 30 or 31 and see if you encounter the same problem.

I'm guessing not so much the distribution, but probably due to the extra extensions that Ubuntu install on their Gnome release by default. Whereas I think Fedora and Debian and others just have a straight setup of Gnome-shell.