GNOME 40's Shell Theme Code Is Rather Expensive But Optimization Pursued

[phoronix]

Phoronix: GNOME 40's Shell Theme Code Is Rather Expensive But Optimization Pursued

It's been a while since last having any major/exciting optimizations to the GNOME desktop to report on by Canonical's Daniel van Vugt that is known for his performance work over the past few years, but some optimizations are forthcoming...

https://www.phoronix.com/scan.php?page=news_item&px=GNOME-40-Expensive-Theme-Code

[nadro]

I really like Gnome overall, but it's bad that all things related to performance/optimisations are "third class citizens" for Gnome developers. Good to all of us that Daniel and few other peoples try to fix those issues.

[xnor]

I really like Gnome overall, but it's bad that all things related to performance/optimisations are "third class citizens" for Gnome developers. Good to all of us that Daniel and few other peoples try to fix those issues.

A new generation of (lazy?) developers that jumped on hip web technologies have infected lots of products and companies. A messenger that used 40 MB memory was considered bloated a few years ago, now we got messengers that use gigabytes of memory with basically the same or even less functionality thanks to hip new web technologies.

I mean JavaScript in the desktop? What an amazing idea... the benefits are outweighed by all the performance issues and image damage it caused to Gnome.

[lumks]

Considering that Shell40 is noticeable faster/more fluent on all of my systems compared to 3.38, I wonder how this is possible.

[Alexmitter]

I mean JavaScript in the desktop? What an amazing idea... the benefits are outweighed by all the performance issues and image damage it caused to Gnome.

KDE also, since Plasma 5 heavily uses JavaScript, its just called QML/QtQuick in the Qt world. And Javascript is not the issue here, alternatives would have been python, lua and other much slower scripting languages. Javascript, from a speed perspective is quite near to native code speed compared to any other scripting language. After all, Javascript is only the glue between highly optimized C gobject functions.

As Daniel van Vugt self noted, most of the shells time, no JS is running at all and if, then those tasks are very minor and have nothing to do with the overall shell performance. All major issues were in mutter and St/Clutter.

KDE Plasma and its apps usually have around 20% JS. Gnome Shell with Mutter has around 10%.

"The important thing to note here is that most of the source code is in the Mutter project, not Gnome Shell. So overall only around 10% of Gnome Shell is written in JavaScript when you consider Mutter, and around 90% written in C."

"Since many users knew Gnome Shell contained JavaScript and that it is an interpreted language, it was easy to blame that. The thing is most people wouldn’t know it’s only 10% JavaScript and that much of the time JavaScript isn’t running at all. Most of the time if you’re just interacting with an application then gnome-shell is running native machine code only, from C."

Source and a good read: https://discourse.ubuntu.com/t/boost...3095?u=vanvugt

[Alexmitter]

I really like Gnome overall, but it's bad that all things related to performance/optimisations are "third class citizens" for Gnome developers. Good to all of us that Daniel and few other peoples try to fix those issues.

If you would look into Danials MR history, then you would see that he himself closes most of his MR. Performance optimizations are a touchy thing, especially on a Desktop/Display Server. Something that may improve one thing may break something else, everything has to be extensively tested.

This is a good read about Daniels work https://discourse.ubuntu.com/t/boost...3095?u=vanvugt

[Volta]

A new generation of (lazy?) developers that jumped on hip web technologies have infected lots of products and companies.

Let's get it straight: generation of clueless developers who have no real clue what they are doing. The truth is the most complicated and performant applications are written in C/C++. Crap languages like c#/mono, java, javascript are unholy jokes when comes to resources. It seems it's impossible to write complex and performant application in any of mentioned unholy programming languages. It's visible everywhere. From graphic engines (unity crap), programming IDEs (slow, buggy, bloated Eclipse - GDB integration is an only selling point for me) to note taking application - tomboy. It's huge regress and waste of computer resources, but every script kiddy can make an application now.. Not saying this is 100% related to Gnome, though. There may be other problems.

[discordian]

I had to uninstall file-roller and deal with archives the commandline way for several weeks. Reason being that opening any archive with file-roller will (almost always) send the gnome 3.38 desktop in a deathspin, flooding the log with javascript errors. The systems so bogged down I cant even switch to a VT.
Drag and dropping files sometimes kills all nautilus instances, sometimes the target (gnome-terminal for me).

I sometimes miss the slow versions (not that the new ones are fast, just less horrible slow) that only had nautilus crash when you searched in a directory that is in heavy use.

Maybe this year I'll buy some Apple PC/Laptop (hate the company, never bought anything from them), and be done with that crap.

[bple2137]

GNOME went from terribly slow to just slow, which is progress at least. That’s good somebody sees the issue and is eager to fix it. GNOME devs dont seem to give a f*ck about it.

[Hibbelharry]

A new generation of (lazy?) developers that jumped on hip web technologies have infected lots of products and companies. A messenger that used 40 MB memory was considered bloated a few years ago, now we got messengers that use gigabytes of memory with basically the same or even less functionality thanks to hip new web technologies.

You miss some facts here. Websites and web technologies have one clear advantage compared to desktop applications: They're cross platform by default. You don't need to write a windows app, a OS X app, an IOS app and a linux app. You build a website and put a os specific frame on it. The frame thing is mostly done by other "volunteers", see for example electron. At first, these apps are most often not totally effective in desktop integration, ressource usage and some other points, but they're available on any platform. You don't need to spend lots of time and money to get an app on all platforms, and I'm quite sure what we wouldn't have seen some apps to appear for linux at all, if this wasn't the case.

Javascript itself is also relatively performant, so don't get that wrong. It's just that websites and 'websites pretending to be an app" aren't that small anymore. People want them to be instant interactive, nice, fancy, fast and consistent across all devices and soon, so web technologies evolved. You might argue that this has lead to extensive usage of pretty all web technologies on any site, and thats true, but we all benefit from that most of the time.

I mean JavaScript in the desktop? What an amazing idea... the benefits are outweighed by all the performance issues and image damage it caused to Gnome.

In my opinion the image damage is mostly done by people without any clue about alternatives, not talking about the real hurdles and the real solutions.