Sysprof Updates

I just uploaded the sysprof-3.33.4 tarball as we progress towards 3.34. This alpha release has some interesting new features that some of you may find interesting as you continue your quests to improve the performance of your system by improving the software running upon it.

An image of Sysprof with various performance graphs

For a while, I’ve been wondering about various ways to move GtkTextView forward in GTK 4. It’s of particular interest to me because I spent some time in the GTK 3 days making it faster for smooth scrolling. However, the designs that were employed there work better on the traditional Xorg setup than they do on GTK 3’s Wayland backend. Now that GTK 4 can have a proper GL pipeline, there is a lot of room for improvement.

Thanks to the West Coast Hackfest, I had a chance to sit down with Matthias and work through that design. GtkLabel was already using some accelerated text rendering so we started by making that work for GtkTextView. Then we extended the GSK PangoRenderer to handle the rest of the needs of GtkTextView and Matthias re-implemented some features to avoid cairo fallbacks.

After the hackfest I also found time to implement layout caching of PangoLayout. It helps reduce some of the CPU overhead in calculating line layouts.

As we start using the GPU more it becomes increasingly important to keep the CPU usage low. If we don’t it’s very likely to raise overall energy usage. To help keep us honest, I’ve added some RAPL energy statistics to Sysprof.

Sysprof design work

Since my last post, I’ve been working on a redesign of Sysprof (among other things) to make it a bit more useful and friendly to newcomers.

Many years ago, I worked on a small profiler project called “Perfkit” that never really went anywhere. I had already done most of my UI research for this years ago, so it was pretty much just a matter of applying that design to the Sysprof code-base.

Now you can individually show extra detail rows and much more. Same great Sysprof 3-part callgraph breakdown.

A screenshot of Sysprof

I’ll get some delayed 3.33.3 tarballs out this week.

Translucent Completion

Sometimes completion windows get in the way of reading the surrounding code. With Builder Nightly, you can press and release Left Control to toggle translucency of the completion window.

Builder 3.33.1

Our first 3.33 release has landed as we move towards 3.34. There is a lot to do this cycle in case you’re interested in contributing. The best way to get started is to dive into the code. We can help you with that on IRC.

Lots of this release is code behind the scenes, so screenshots won’t do them justice. But there are some visible goodies too.

We got a D-Bus Inspector inspired by D-feet. The long term goal is to merge that new code into D-feet itself.

Occasionally we got issues filed about not being able to half-tile Builder. The smaller your screen size, the more unrealistic of an expectation that is, but we can certainly do a little better. The new search box takes up less space and animates in as necessary.

We gained some initial Podman support so long as your system has support for podman exec --preserve-fds. You can even debug inside the containers if they have gdb in the container.

Some users were surprised by how Builder auto-downloaded SDKs and Runtimes to build projects. So we’ve added a confirmation dialog to that process so the user can make informed decisions.

I’ve also moved Git integration out of process. Both the Git and Flatpak plugins previously used git in process which had a number of drawbacks. We created some new API and the gnome-builder-git daemon which provides access to common git operations using libgit2-glib and D-Bus serialization binary format over stdin/stdout. We have push, stage, and signed commit support, but that currently lacks UI in this release.

GtkSourceView moved to Meson

The master branch of GtkSourceView (what will become 4.4) has moved to meson for development. I branched gtksourceview-4-2 for patch releases of 4.2.x which will remain autotools. Today’s release of gtksourceview-4.3.1 contains both autotools and meson. However 4.3.2 will remove autotools entirely.

I also landed some code to speed up line number drawing which was a non-trivial amount of the render cost while kinetic scrolling.

Using Leak Sanitizer with JHBuild

For a subset of GNOME modules, I’m still using jhbuild. I also spend a great deal of time tracking down memory bugs in various libraries. So it is very handy to have libasan.so working with meson -Db_sanitize=address.

To make things work, you currently need to:

  • dnf install libasan liblsan (or similar for your OS).
  • Use meson from git (0.48 development), for this bug fix.
  • Configure your meson projects with -Db_sanitize=address.
  • Create a suppression file for leaks out of our control.
  • Set some environment variables in ~/.config/jhbuildrc.

Here is an example of what I put in ~/.config/lsan_suppressions.txt.

leak:FcCharSetCreate
leak:FcLangSetCreate
leak:__nptl_deallocate_tsd
leak:_g_info_new_full
leak:dconf_engine_watch_fast
leak:g_get_language_names_with_category
leak:g_intern_string
leak:g_io_module_new
leak:g_quark_init
leak:libfontconfig.so.1

And add this to ~/.config/jhbuildrc.

import os
os.environ['LSAN_OPTIONS'] = 'suppressions=' + \
    os.path.expanduser('~/.config/lsan_suppressions.txt')

This has helped me track down a number of bugs in various modules this week and it would be useful if other people were doing it too.

Engineering Journals vs User Support

A major thanks to everyone involved in the gitlab migration. It’s no doubted a huge leap forward for GNOME on so many fronts.

Before we lose that momentum, I’d like to bring up in the collective minds of our project, what I consider, a separate problem. That is Bug Tracking versus User Support.

We’ve gotten a lot of flack over the years for brash or abrupt comments in our bug trackers. And while I can see that from a certain angle, I think in many cases it’s due to the miss-use of bug trackers as a user support mechanism.

For example, I’ve always seen a bug tracker as an engineering journal: a way to keep track of symptoms, potential solutions and trade-offs, and finally, the chosen solution. One valuable aspect to this is that you don’t have to go mucking through unrelated information or prose to pick out the valuable bits. In other words, terseness.

Where as user support has a different focus. The focus is on the user and their symptom, making them feel heard, and do our best to convert that information into a succinct chain of information for the engineering journal.

Treating engineering journals and user support as equivalent is preventing us from doing either with proficiency.

We generally don’t have this focus in F/OSS. It requires a set of skills that many of us have not cultivated and probably should. In addition, we should encourage those that already have these skills to join us.

But that raises the question: is gitlab the right place to do user support?

If GNOME were to advance Free Software by taking user support to the next level, what would that look like and what tooling do we need? Is that worth investing in now that we have many applications to support in addition to the desktop plumbing?

Hopefully we can have some discussion about that on the beach in Almería, Spain for GUADEC 2018.

More compiler fun

Yesterday’s post about -fstack-protector challenges leads us to today’s post. If you haven’t read it, go back and read it first.

Basically, the workaround I had at the time was to just disable -fstack-protector for the get_type() functions. It certainly made things faster, but it was a compromise. The get_type() functions can have user-provided code inserted into them via macros like G_DEFINE_TYPE_EXTENDED() and friends.

A real solution should manage to return the performance of the hot-path back to pre-stack-protector performance without sacrificing the the protection gained by using it.

So I spent some time today to make that happen. In bugzilla #795180 I’ve added some patches which break the get_type() functions into two. One containing the hot path, and a second that does the full type registration which is protected by our g_once_init_enter(). If we add the magic __attribute__((noinline)) to the function doing the full type registration, it can’t be inline’d into the fast path allowing it to pass the stack-protector sniff test (and therefore, not incur the stack checking wrath).

The best part is that applications and libraries only need to be recompiled to get the speedup (due to macro expansion).

Not a bad experience diving into some compiler bits this week.

Device Integration

I’ve been working on some groundwork features to sneak into Builder 3.28 so that we can build upon them for 3.30. In particular, I’ve started to land device abstractions. The goal around this is to make it easier to do cross-architecture development as well as support devices like phones, tablets, and IoT.

For every class and kind of device we want to support, some level of integration work will be required for a great experience. But a lot of it shares some common abstractions. Builder 3.28 will include some of that plumbing.

For example, we can detect various Qemu configurations and provide cross-architecture building for Flatpak. This isn’t using a cross-compiler, but rather a GCC compiled for aarch64 as part of the Flatpak SDK. This is much slower than a proper cross-compiler toolchain, but it does help prove some of our abstractions are working correctly (and that was the goal for this early stage).

Some of the big things we need to address as we head towards 3.30 include running the app on a remote device as well as hooking up gdb. I’d like to see Flatpak gain the support for providing a cross-compiler via an SDK extension too.

I’d like to gain support for simulators in 3.30 as well. My personal effort is going to be based around GNU-based systems. However, if others join in and want to provide support for other sorts of devices, I’d be happy to get the contributions.

Anyway, Builder 3.28 can do some interesting things if you know where to find them. So for 3.30 we’ll polish them up and make them useful to vastly more people.