![]() So any pauses could cause them to miss the next frame and exhibit stuttering. Gnome Shell and Mutter are single-threaded Glib event loop apps. If you measure real time you will catch both real time and CPU problems. So even if your program is CPU-bound it’s still a useful measurement to start on. Real time is also a superset of CPU time. And that’s mostly on purpose – you do want your system to be idle and consume minimal power when you’re not interacting with it. In the case of a single-threaded event-driven program like Gnome Shell it is the time spent in poll() and other blocking code that makes the system idle most of the time. That’s not using any CPU time or GPU time but you know it’s going to take a while to finish. Real time usage is the 123 when you run sleep 123. Such cold spots are only apparent when you look at the real time usage of a program, and in not the CPU or GPU time consumed. They were better characterised as cold spots where it was idle instead of updating the screen smoothly. The thing is in the case of Gnome Shell its biggest performance problems of late were not hot spots at all. ![]() Typically you profile your program and look for hot spots using the most CPU or GPU time. There are decades of knowledge on how to do that. Most of the time if you’re just interacting with an application then gnome-shell is running native machine code only, from C.ĭevelopers on the other hand tend to focus on CPU usage and GPU usage. 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. Since many users knew Gnome Shell contained JavaScript and that it is an interpreted language, it was easy to blame that. Perhaps more surprisingly even if you have a fast machine then it still would not run completely smoothly. ![]() If you have a slow machine then it won’t run smoothly. Gnome Shell 3.32 in Ubuntu 19.04 feels slower than Unity and other desktops. ![]() So overall only around 10% of Gnome Shell is written in JavaScript when you consider Mutter, and around 90% written in C. The important thing to note here is that most of the source code is in the Mutter project, not Gnome Shell. Gnome Shell is made up of 199 C source files and 157 JavaScript source files (at the time of writing). The Gnome Shell project is the smaller of the two projects, adding bling like the desktop panel and launcher, similar to how Unity 7 sits on top of Compiz. While most of the Mutter project is used as libraries by Gnome Shell, a mutter command also exists as a standalone compositor if all you need is a mouse pointer and wallpaper. Mutter is comprised of 1389 C source files (at time of writing). The majority of the logic is in the Mutter project, which includes the Clutter and Cogl graphics toolkits. It is a desktop environment written in C and JavaScript on top of the Mutter compositor/window manager. Let’s get this right because many people don’t and it leads to unfair criticism of Gnome Shell. In this article we will describe some of the improvements contributed by Canonical, how the problems were surprising, how they were approached and what other performance work is coming in future. Boosting the Real Time Performance of Gnome Shell 3.34 in Ubuntu 19.10Īs you may have read many times, Gnome 3.34 brings much improved desktop performance.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |