4 ms·

Is the issue JS as an extension language, or is it using JS for core events? Or maybe something else? People write successful games with Pygame, and Python's

Is the issue JS as an extension language, or is it using JS for core events? Or maybe something else? People write successful games with Pygame, and Python's VM is much less optimized than what's available in the JS world, even in 2010. To get 1-frame response time, you need to poll and redraw in the same 16.67ms window. That's an eternity inside a computer. I can write a JS curses app using blessed and it feels pretty snappy, so I'm guessing JS isn't the fundamental problem. The GNOME folk have always been a fan of IPC though (remember ORBit?), so I wouldn't be at all surprised if the latency is due to context switching.

dleslie 6y ago
JS in 2010 was not nearly as efficient or fast as it is today. But yes, it was a number of things as well as Javascript. It was entirely possible to spend time in stock Gnome3 without executing JS with any meaningful frequency, because the core Gnome shell doesn't really have much; but being the extension language, using any Gnome3 extensions would immediately bring JS into the profile. Being someone who likes to customize my desktop, and typically uses hardware five or more years out of date, the Javascript was a pain point for me. There's an excellent blog post from 2019 by one of the Ubuntu devs regarding their efforts at the time to fix Gnome3, as they were abandoning Unity: https://discourse.ubuntu.com/t/boosting-the-real-time-performance-of-gnome-shell-3-34-in-ubuntu-19-10/13095 https://discourse.ubuntu.com/t/boosting-the-real-time-perfor... Going farther back, Gnome3 was plagued with lots of similarly bad design decisions, like allocating and freeing large amounts of memory on the same thread that handles animation rendering: https://bugzilla.gnome.org/show_bug.cgi?id=745032 https://bugzilla.gnome.org/show_bug.cgi?id=745032 It's quite a storied history for Gnome3 performance; it's come a long way in the last decade. Sadly, it's still nowhere near as responsive or efficient as Gnome2/MATE.

dleslie 6y ago

JS in 2010 was not nearly as efficient or fast as it is today. But yes, it was a number of things as well as Javascript. It was entirely possible to spend time in stock Gnome3 without executing JS with any meaningful frequency, because the core Gnome shell doesn't really have much; but being the extension language, using any Gnome3 extensions would immediately bring JS into the profile. Being someone who likes to customize my desktop, and typically uses hardware five or more years out of date, the Javascript was a pain point for me. There's an excellent blog post from 2019 by one of the Ubuntu devs regarding their efforts at the time to fix Gnome3, as they were abandoning Unity: https://discourse.ubuntu.com/t/boosting-the-real-time-performance-of-gnome-shell-3-34-in-ubuntu-19-10/13095 https://discourse.ubuntu.com/t/boosting-the-real-time-perfor... Going farther back, Gnome3 was plagued with lots of similarly bad design decisions, like allocating and freeing large amounts of memory on the same thread that handles animation rendering: https://bugzilla.gnome.org/show_bug.cgi?id=745032 https://bugzilla.gnome.org/show_bug.cgi?id=745032 It's quite a storied history for Gnome3 performance; it's come a long way in the last decade. Sadly, it's still nowhere near as responsive or efficient as Gnome2/MATE.