Performance rework: what changed and what I have learned (new release v8.0)

[tommy-gun]

The last weeks I spent on a bigger internal rework of the extension. Here are the results with real numbers, and a few things I learned on the way.

What the rework brings

The main goal was a redesign of the internals, so that new features are easier to build on top of a clean data/UI separation. But the rework also gave a good opportunity to fix the long-standing performance problems, and that part is easy to show in numbers. Measured with GSE Profiler on the same set of feeds, same scenario (one new item arriving), before and after:

	before	after
Longest single main-thread stall (background poll)	85 ms	14 ms
Longest single main-thread stall (Minimal layout open)	91 ms	20 ms
Feed processing per refresh	128-174 ms	~20 ms
Total main-thread cost per refresh	132-260 ms	49-106 ms

The most important line is the first one. 85-91 ms on the main thread means 5-6 skipped frames, which means a visible stutter of the whole shell on every feed refresh. Now the worst block stays around one frame on my setup, so the refresh should be much less noticeable, if at all. If you still see stutter with your feeds, please report it; that is exactly the data I need.

How it was achieved:

• New XML parser. Replaced the old REXML library with lightweight tXml. Feed processing dropped roughly 5-9× depending on feed size.
• One rebuild instead of four. Before, every downloaded feed triggered a rebuild of the open menu: one poll cycle did 4 full rebuilds (73 ms together). Now the updates are coalesced and the menu rebuilds once (20 ms).
• Rendering in small chunks. The menu items are rendered in idle-time chunks of 10 items, each chunk ~5-7 ms, so nothing blocks a frame even with many articles.
• Batched state writes. Read/unread state was written to GSettings after every single feed (9 writes per poll). Now it is flushed once per cycle.

Screenshots from the profiler, background poll before/after:

And the same for a refresh with the Minimal layout open. Note the hottest function changed from feed processing (174 ms) to chunked rendering (30 ms split into 6 small pieces):

Architecture: data and view are now separate

The old code had one big indicator class doing everything: downloading, parsing, storing state and building the menu. The rework splits it into components with one job each:

• FeedPoller: downloads and parses the feeds,
• FeedStore: in-memory model of sources and articles,
• FeedRepository: persistence (read/unread state, per-feed settings),
• NotificationManager: decides what to notify and talks to the Shell tray,
• UI layer (indicator, Classic/Minimal layouts): only renders what the store contains.

The UI never touches the network or parsing anymore, it just reacts to store changes. Besides being easier to maintain, this had a nice side effect on profiling: in the "before" captures everything hides inside one _onDownload function, in the "after" captures you can see exactly which component costs what. Finding the remaining bottlenecks took minutes, not hours.

Fix for light themes (Yaru and others)

The old stylesheet had hardcoded white colors, so on Ubuntu with Yaru light theme parts of the UI were white text on light background (#31). Lessons:

• don't hardcode text colors, use opacity for dimmed text and let the theme provide the foreground color,
• for hover/badge backgrounds use neutral gray with alpha (rgba(127,127,127,0.15)), it works on dark and light,
• use -st-accent-color in CSS instead of hardcoded blue,
• runtime-generated SVG icons can't use theme variables, so the accent color is read from GSettings and mapped to hex manually.

GNOME 46 / 47 / 48 differences

Some features depend on what the Shell itself provides:

• Accent color (47+). The accent-color key in org.gnome.desktop.interface exists only since GNOME 47, on 46 reading it crashes. I first dropped GNOME 46 support, then realized 46 is Ubuntu 24.04 LTS and brought it back with a guard: settings_schema.has_key() is the safe way to probe keys that may not exist on older shells. On 46 the unread badges fall back to a neutral gray.

• Notification grouping (48+). The "Group notifications by source" option relies on the Shell grouping notifications by app, which arrived in GNOME 48. On 46 and 47 the Shell lists every notification separately, so the option has no effect there.

About the numbers

Two methodology notes so the comparison is fair: both captures use the same feeds with exactly one new item and a warmed-up notification path (the very first notification after shell start pays ~24 ms for creating the tray source, every next one 5-8 ms). And the parsing improvement is reported as a range (5-9×), because feed payloads differ between runs. I prefer honest milliseconds over one impressive number.

Release and what's next

The new release is available on GitHub now, and on EGO soon after the review passes.

One more thing: I would like this extension to be community driven, not a one-man show. So if you use it, join the discussions here, open issues when something breaks, request features you miss. Feedback from real usage is worth more than any profiler capture.

Thanks to everyone who reported issues and suggested improvements so far. The light theme fix exists because somebody took the time to report it, and several code improvements came from reviewer feedback. That is exactly how I hope this will work going forward.