Geometric Picking Finally Lands In GNOME/Mutter 3.34 For Lowering CPU Usage

[boxie]

Well, one thing is for sure. Mutter is already startling compared to say a year/year & a half ago, and the numbers on this new patch are quite remarkable, so ubuntu 19.10 should be a revelation for anyone on 18.04. And hats off to the decision-makers who pulled in the MR at the last moment. I think the praise which will follow this next gnome release will make everyone feel quite good about the co-operation behind these performance improvements.

so I have a genuine question - I was using an ubuntu 19.04 live cd the other day (amd cpu+gpu) and gnome felt "slow". As this is my only experience recently - are you saying that a 19.10 live cd (assuming it has gnome 3.34 and ignoring live usb disk access penalties) should feel snappy? If so, that could be quite cool!

[timrichardson]

so I have a genuine question - I was using an ubuntu 19.04 live cd the other day (amd cpu+gpu) and gnome felt "slow". As this is my only experience recently - are you saying that a 19.10 live cd (assuming it has gnome 3.34 and ignoring live usb disk access penalties) should feel snappy? If so, that could be quite cool!

I think what I'm saying is for sure you would not like 18.04 I found 19.04 to be a big step forwards, so did many reviewers. But I use it on intel and optimus laptops, I don't yet have any AMD hardware. And we refer specifically to mutter stuff: composition, not things like app launching (in other words, for the scope of this, there can't be a USB penalty).

[Britoid]

so I have a genuine question - I was using an ubuntu 19.04 live cd the other day (amd cpu+gpu) and gnome felt "slow". As this is my only experience recently - are you saying that a 19.10 live cd (assuming it has gnome 3.34 and ignoring live usb disk access penalties) should feel snappy? If so, that could be quite cool!

Try Fedora, Ubuntu ships with older versions of Mesa, still uses Xorg and bundles GNOME extensions famous for causing performance issues (e.g. Desktop Icons). It never has been the greatest example of GNOME.

timrichardson True. This work brings many benefits. But it’s not without cost to have developers like vanvugt. He puts a lot of peer pressure on the maintainers because he tags most MRs as performance related and use hyperbole commit messages.

statistics on closed MRs: 41 of 113 came from vanvugt. That’s too much and basically a behavioral problem.

There's also extra wasted time when regressions/bugs for these unmerged patches get filed upstream because downstream distros have shipped them by default in their stable repos.

[starshipeleven]

boxie it’s smooth on a single core VM.

Single core in the sense of "restricted to the usage of 1 core" or "exposing 1 core to the VM"

Because afaik Virtualbox and VMWare don't restrict core usage. They can fool the VM into thinking it's running on a single core but in practice you see more than one core used on the host.

[FireBurn]

What is the point of having release candidates if they pop things like this in days before a release? Either include it in the next release, or if the patch is worth waiting for, delay the release and get it tested by users

[starshipeleven]

I can’t see how a VM can pull of any magic when the host need to run as well.

Virtualbox or VMWare Workstation/player VMs are just a bunch of processes running on the host. That's what Type 2 Hypervisors do https://en.wikipedia.org/wiki/Hypervisor.

Giving the VM multiple cores in these programs only means you let the guest VM's OS split its own processes over available cores instead of relying on the hypervisor to do it. It's generally better to do that if the guest VM OS is capable of multi-core operation as the guest OS usually knows better than the hypervisor. But still, the hypervisor can split things up in multiple processes, even if inefficiently, so you can't claim the VM is "running in single core".

You are not fully dedicating a core to the VM (i.e. removing its access to the host system) unless you are actually asking for this feature and using a Type 1 Hypervisor like KVM, Xen, Esxi, Hyper-V and friends.

For example, I have 2 VMs open at the moment in VMWare Workstation, each with 4 cores "assigned" to each, so total 8 cores "needed".

The host is a 4 core CPU (tecnically it's a dualcore with HT because it's a laptop CPU), and it's fine.

[royce]

The Canonical dev's contributions in that thread are a masterpiece of patience and control, as it took a year and lots of obstruction to get the patch merged,despite overwhelming evidence in his favour.

You can say that again. A ton of his pull requests have been blocked for months for stuff as important as commit messages not to the taste of Stavracas, for instance. Daniel has been schooling them for two years now on their shoddy code and they absolutely hate him for it, even though they're responsible for the abysmal state of gnome shell and mutter in terms of performance.

[amehaye]

so I have a genuine question - I was using an ubuntu 19.04 live cd the other day (amd cpu+gpu) and gnome felt "slow". As this is my only experience recently - are you saying that a 19.10 live cd (assuming it has gnome 3.34 and ignoring live usb disk access penalties) should feel snappy? If so, that could be quite cool!

Some delays in the GNOME desktop are intentional. For example, this extension https://extensions.gnome.org/extensi...delay-removal/ removes the ~0.5 second delay before the popup appears after pressing ALT-TAB to switch between application windows. Not sure why there are various intentional delays in the UI, but evidently some of them can be bypassed.

[ernstp]

What is the point of having release candidates if they pop things like this in days before a release? Either include it in the next release, or if the patch is worth waiting for, delay the release and get it tested by users

This is a very good question, though this particular commit seem to have been pretty well tested by multiple users. Still defeats the purpose of release candidates and freezes though...

In Gnome 3.28 there was so much bugs, it took very long time to patch that up https://gitlab.gnome.org/GNOME/mutte...its/gnome-3-28 . No trace of "Mutter is used on enterprise class distributions. You can’t allow that to regress." there...

[ernstp]

I think what I'm saying is for sure you would not like 18.04 I found 19.04 to be a big step forwards, so did many reviewers. But I use it on intel and optimus laptops, I don't yet have any AMD hardware. And we refer specifically to mutter stuff: composition, not things like app launching (in other words, for the scope of this, there can't be a USB penalty).

They've been maintaining Gnome in 18.04 very well and backporting patches, it's quite ok. And you have the Ubuntu HWE 18.04.3 stuff also...