Seriously - today so far it has used 1 hour 15 mins of CPU time! In that time, we could have computed pi to billions of digits, yet somehow all gnome-shell has to show for it is that it managed to keep a clock updated and occasionally switch apps.
I finally dived into what was consuming all the CPU time in gnome-shell. Turns out most of it was spent in clutter_actor_finish_layout in clutter-stage.c, part of gnomes layout engine.
The function runs fast, but was being run thousands of times per second. Every object on the screen (ie. every menu icon, every status icon, every bit of text) was having its position recalculated at 60 fps.
Someone has already noticed and fixed the bug:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679
So in 12 months time, the fix will hopefully make it to everyones distros releases. Till then, enjoy the warm lap.
Last I heard clutter was no longer being maintained, and that was several years ago.
If you're still on X I'd expect more of the compositing cost reflected in the Xorg process than gnome-shell.
But on a "modern" Wayland-based gnome session, the gnome-shell process encompasses what used to occur in Xorg. So all that time is now attributed to gnome-shell.
It's not like you just arrange the GPU with some buffers and never wake up to send it commands on what to draw when. The compositor is a rather busy process, esp. if you have many clients/windows active.
This stuff was easier to reason about in the Xorg days with WM "policy" running in a clearly separate process from the X "mechanism" side. Wayland tends to conflate everything, unless the compositor developers choose to use separate well-labeled threads for things like input/compositing/policy...
I don't personally use gnome so it's inconvenient for me to check despite mild curiosity. It may be interesting to look at a threaded view of `top` if you're on Wayland, and see if gnome-shell has clearly separated threads.
Interestingly, modern Xorg uses separate threads now, from this machine:
524 anon 20 0 637516 92996 53592 S 5.3 0.6 82:54.35 Xorg
525 anon 39 19 637516 92996 53592 S 0.0 0.6 0:00.00 Xorg:disk$0
526 anon 20 0 637516 92996 53592 S 1.0 0.6 36:32.18 Xorg:gdrv0
527 anon 39 19 637516 92996 53592 S 0.0 0.6 0:00.00 Xorg:disk$0
529 anon 20 0 637516 92996 53592 S 1.0 0.6 1:10.52 InputThread
If this were a Wayland situation, that time would be reflected in my compositor process instead.
~83 hours for the main Xorg thread, which I presume is largely IPC but X also does heaps of crap from its huge protocol on-CPU so I think it's best to just ignore that.