4 ms·

Well you compare a heavy JavaScript based DE (Gnome) with a C++ one (KDE, with Qt). That's also unfair. But if you try i3 or OoenBox, they are way faster

non-entity 7y ago
> But if you try i3 or OoenBox, they are way faster But those are just window managers no? You can run them alongside KDE or Gnome.
- michaelmrose 7y ago
  Gnome 3 doesn't let you configure an alternative wm. KDE does but it's broken by default with minimal wm. For example it wants to start a full screen window that would normally be the desktop interface over everything. It's questionable how much value is added by running a plasma session over simply running KDE apps and services.
  - ohithereyou 7y ago
    Eventually, you won't really have a choice about whether to run a desktop session once Wayland is here. I don't expect my favorite window mamager to be updated with Wayland support.
    - majewsky 7y ago
      Which window manager is that? For i3, the Wayland equivalent (or at least 99% equivalent) is Sway (which I'm using right now over here). For Awesome, there's way-cooler.
      - ohithereyou 7y ago
        WindowMaker
purple_ducks 7y ago
from the article: > Canonical's write-up of the work done to improve GNOME is also interesting for the long list of what didn't work and how wrong some of the developers' initial assumptions were—especially regarding GNOME's use of JavaScript. > It turns out JavaScript had next to no effect on performance. So sorry JavaScript haters, but "assuming that JavaScript is slower than everything else written in C" is evidently a bad assumption
- michaelmrose 7y ago
  In 2011 gnome 3 was released with a memory leak due to a mismatch between compiled code and Javascript which saw memory allocated during animations that would be freed in no reasonable time frame. Eventually all memory in the system belongs to gnome shell. As this is really hard to fix they fixed this by constantly running the gc in December 2018. This worked OK but didn't fix the issue for all until 2019. Does making it broken for 8 years so usability comes 8 years late count as making it slow.
- zozbot234 7y ago
  It should be noted that 3.34 has also seen some work on moving stuff from JS to C. Notably animations are now far less dependent on the JS part, with better performance as a result.
Matthias247 7y ago
Be aware that QTs QML makes use of a Javascript variant too.

non-entity 7y ago

> But if you try i3 or OoenBox, they are way faster But those are just window managers no? You can run them alongside KDE or Gnome.

michaelmrose 7y ago
Gnome 3 doesn't let you configure an alternative wm. KDE does but it's broken by default with minimal wm. For example it wants to start a full screen window that would normally be the desktop interface over everything. It's questionable how much value is added by running a plasma session over simply running KDE apps and services.
- ohithereyou 7y ago
  Eventually, you won't really have a choice about whether to run a desktop session once Wayland is here. I don't expect my favorite window mamager to be updated with Wayland support.
  - majewsky 7y ago
    Which window manager is that? For i3, the Wayland equivalent (or at least 99% equivalent) is Sway (which I'm using right now over here). For Awesome, there's way-cooler.
    - ohithereyou 7y ago
      WindowMaker

purple_ducks 7y ago

from the article: > Canonical's write-up of the work done to improve GNOME is also interesting for the long list of what didn't work and how wrong some of the developers' initial assumptions were—especially regarding GNOME's use of JavaScript. > It turns out JavaScript had next to no effect on performance. So sorry JavaScript haters, but "assuming that JavaScript is slower than everything else written in C" is evidently a bad assumption

michaelmrose 7y ago
In 2011 gnome 3 was released with a memory leak due to a mismatch between compiled code and Javascript which saw memory allocated during animations that would be freed in no reasonable time frame. Eventually all memory in the system belongs to gnome shell. As this is really hard to fix they fixed this by constantly running the gc in December 2018. This worked OK but didn't fix the issue for all until 2019. Does making it broken for 8 years so usability comes 8 years late count as making it slow.
zozbot234 7y ago
It should be noted that 3.34 has also seen some work on moving stuff from JS to C. Notably animations are now far less dependent on the JS part, with better performance as a result.

Matthias247 7y ago

Be aware that QTs QML makes use of a Javascript variant too.