GNOME Bugzilla – Bug 450272
Profile whether using bitfields increases or reduces memory-time
Last modified: 2020-11-06 20:08:39 UTC
Elijah in bug 376760: >As another > side note, it'd be interesting to find out whether these bitfields actually > help performance (reducing memory costs a little bit and making it more likely > things are in cache) or hurt (more code to access the relevant fields).
Created attachment 90505 [details] [review] Patch for testing with/without
You probably want to bias toward less memory; lots of times caches are a win in a benchmark for one app, but for the whole desktop keeping code and heap small can end up being more helpful. At least anecdotally, supposedly -Os can beat -O2 a lot of the time, too. I'm not sure how you'd objectively decide one way or the other, since the overall picture is very complicated and depends on particular hardware and workload. From a user-visible standpoint, remember that CPU usage to do an operation is either user-visible (above some threshold like 100 milliseconds) or it isn't (anything below the perceivable threshold). So often for GUI apps, as long as you're under that threshold, CPU optimization is totally worthless, even if a benchmark shows you've gone from 30ms to 10ms, it just doesn't matter. Memory optimization on the other hand has incremental value because lots of little memory optimizations can add up to a large global saving in the desktop's working set, which means perceptibly less swapping. The same principle can apply to CPU if you have an operation like 'draw a rectangle' that is frequently combined into a series of similar operations, if you do 10 of those then 30ms vs. 10ms each is the difference between perceptibly slow or not for the entire 10 (300ms vs. 100ms). On the other hand, if the operation is an entire user-visible atomic operation like "move a window," and it's below the threshold where people would feel it's slow, then it doesn't matter. Remember too that people often describe something as "slow" when the real problem is e.g. flicker or the visibility of intermediate states or artifacts. With GTK+ 1.2 this was common, stuff would benchmark fast but be perceived as slow due to flicker.
(marking patch as needs-work to get it off the unreviewed queue where it doesn't belong)
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.