Live and recent posts from across the Fediverse tagged #sysprof, aggregated by home.social.
PSA to #infosec researchers reporting issues on desktop software: y'all, a simple CPU-hogging performance issue where we're showing too many widgets (instead of a summary when importing a large file) is not a "Denial of Service", come on :blobmiou:
Sometimes, a cigar is just a cigar.
https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1632
#MaintainerLife #QA #GNOMECalendar #Sysprof #performance #GNOME #security #Linux #OpenSource
Encountered a #Poppler bug report with an attached sample PDF document that takes over 45 seconds to render its first page on my fastest computer, so I took the opportunity to profile it with #Sysprof : https://gitlab.freedesktop.org/poppler/poppler/-/work_items/1572#note_3592829
Since I use the "dnf debuginfo-install" command so often (instead of debuginfod) to cleanly install debug symbols for apps and libraries on #Fedora, which lets me get meaningful backtraces for crashes reporting or sysprof performance profiling, I figured I might as well request the ability to autocomplete filenames with Tab: https://github.com/rpm-software-management/dnf-plugins-core/issues/623
For a long time I've been intrigued by #Epiphany taking 3 to 20 seconds to load most websites on startup or in Incognito Mode.
Today I tested a bunch of configurations to report a bug, profiled… and it turned out to be 2 bugs in 1 :blobsweats:
* The adblocker (and similar features) makes things slower :psyduck: : https://gitlab.gnome.org/GNOME/epiphany/-/work_items/2880#note_2766101
* WebKitGTK is doing some shenanigans with the system's fonts: https://bugs.webkit.org/show_bug.cgi?id=315135
#GNOMEWeb #WebKitGTK #GNOME #Sysprof #profiling #performance #Linux
Stumbled upon another good example of a simple WordPress website theme causing scrolling performance problems in the latest version of GNOME Web (Epiphany), so I profiled the heck out of it with about 3.6 gigabytes of @WebKitGTK debug symbols installed: https://bugs.webkit.org/show_bug.cgi?id=310814
#QA #Sysprof #performance #profiling #GNOMEWeb #Epiphany #GNOME #WebKitGTK #WebKit
Reported a new performance issue in Firefox's vertical tabs: resizing the width of that sidebar is extremely laggy, no matter the amount of tabs: https://bugzilla.mozilla.org/show_bug.cgi?id=2021898
Thankfully, I was able to use Sysprof for this, because Firefox's built-in profiler crashes.
I stumbled upon a 2300-pages-long PDF document that actually is a fantastic benchmark for slow search performance (1.5 to 5 minutes) in most PDF readers (including GNOME Papers, Evince and Okular)… so I fired up #Sysprof through GNOME Builder to measure the slowness, and reported my findings in #Poppler for all of you performance optimization aficionados: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1660
#PDF #profiling #performance #FreeDesktop #Linux #GNOMEBuilder #GNOME #GNOMEPapers #Evince #Okular
Discovered today that Epiphany (and presumably any application using #WebKitGTK) will experience slow scrolling after resizing the webview (or window) on some websites, particularly when you drag the scrollbar using the mouse (instead of using the scrollwheel), as can be seen in the video below.
I have reported it here: https://bugs.webkit.org/show_bug.cgi?id=305290
Wondering if anyone experiences this on web pages other than this article: https://thewalrus.ca/return-to-office-mandates/
A performance testing surprise I did not have on my bingo card this month: #gitg being 3 times slower to reload a git repository compared to the initial load. It… it can't be! :blobsweats:
5 days ago, I encountered a "somewhat serious, but niche" performance bug in #Inkscape where it would lock up the whole application while eating the CPU for 10 minutes when ungrouping thousands of objects at once (hello, EPS-imported files with text!).
I profiled it with #Sysprof and full debug symbols, and reported it here: https://gitlab.com/inkscape/inkscape/-/issues/5988
I thought, "Eh, 3.6+2.1K open issues? We'll see when they get to it 🤷"…
Well… Yesterday, one of the @inkscape devs just fixed it! Impressive :owi:
@clemej Better than "top" would be to install all debuginfo packages and measure with #Sysprof, maybe there is a performance bug that can be reported and solved there. See this guide: https://fedoramagazine.org/performance-profiling-in-fedora-linux/
HiDPI in #GNOME is a great way to easily spot interesting performance issues.
I tried out #GNOMEConnections to #RDP to a laptop that has a 4K display, and discovered that it's extremely slow compared to #Remmina connecting to that same machine:
* High CPU usage when the window is focused and idle (no mouse cursors moving, no animations)
* The client-moved cursor lags on the remote host
* Moving windows lags a lot
Reported as:
* https://gitlab.gnome.org/GNOME/gnome-connections/-/issues/191
* https://gitlab.gnome.org/GNOME/gnome-connections/-/issues/192
maybe someone is interested:
I was compiling gnome-inform just copy and pasting the instructions by @ptomato
this just works
https://github.com/ptomato/inform7-ide/blob/main/BUILD.md
at the end i have a working build of a fresh inform7-ide. and with my most famous bug:
https://inform7.atlassian.net/browse/I7-2240
is anyone good in using #sysprof ?
to use it just with the terminal i use this command:
./inform7/Tangled/inform7 -project "~/adventure.inform/" -format "Inform6/16" && ./inform6/Tangled/inform6 -E2w~SDG ~/adventure.inform/Build/auto.inf -o ~/adventure.inform/Build/adventure-built.ulx
it takes the inform7 source text, compiles it to inform6, creates the .ulx file, which you can "play" using glulx.
and yes, i would like to have that bug fixed ;)
Using #Scribus again for the first time in many years, and while 1.6.4 seems a bit more robust than 1.4-1.5x were… boy, does this thing have room for performance optimizations. I keep getting GUI hangs with 100% CPU usage for 5-10 seconds at a time on every (de)selection or layer reassignment for photographs.
I wonder if it would help the devs if I ran #sysprof all over the place to report such issues. I dread having to use the "Mantis" bug tracker again, though.
When I hand-coded that static HTML+CSS in 2013-2019, I did not realize that my personal website's "Clients" logos wall page would remain one of the best scrolling performance benchmarks for #WebKitGTK even in 2025 with Skia and a triple-buffered #GNOME 48, but here we go… fresh #Sysprof captures where that page casually brings the framerate down from 60fps to 12-18fps: https://bugs.webkit.org/show_bug.cgi?id=221738#c26
Attempted to profile #LibreOffice's sluggish/janky window resizing performance under Linux with #Sysprof, on Fedora 42 / GNOME 48, and I am not sure my test setup is entirely correct… because I somehow end up with Cairo everywhere instead of Skia, even if I tell the app to use Skia (anyone knows how to ensure it's actually using Skia in practice?): https://bugs.documentfoundation.org/show_bug.cgi?id=160015#c5
With everything going on in #WebKitGTK's port to Skia, performance optimizations in GNOME Shell and Mutter, optimizations related to libsoup, #Sysprof profiling marks for WebKitGTK… I ended up waiting for 1.5 years to reprofile some bloated news websites that are slow to load in #GNOMEWeb. Today, I did that: https://bugs.webkit.org/show_bug.cgi?id=291796
Wake up babes, new web browser engine benchmark just dropped (a fintech banking website's CPU-devouring front page text carousel):
* https://bugs.webkit.org/show_bug.cgi?id=291791
* https://bugzilla.mozilla.org/show_bug.cgi?id=1954307
It occurs to me that the UX of #Sysprof for the "launch the app from Sysprof" scenario could be improved if there was a way for it to "mark" (a.k.a. "milestone") various points of the timeline with annotations, including the ability to create such milestones in realtime through a global keyboard shortcut, then labelling them after the recording is done.
That way, you could have a clear visual way to know which specific parts of the timeline your measurements for action X, action Y, etc. are in.
The simultaneously exciting and exhausting thing about #GNOME 48 with dynamic double-triple-buffered Mutter—sitting atop of all the other performance optimizations that happened in GNOME Shell and Mutter over the past 2 years—is that now there will be no more excuse for GPU jankiness throughout the desktop: everything even slightly janky will be "Bring out #Sysprof and reprofile every damned app with the 48.x stack!" :blobsweats:
Opportunistic #Sysprof performance profiling of #Liferea's "Mark all as read" action on my huge local #SQLite database of #RSS syndication feed items: https://github.com/lwindolf/liferea/issues/1422
Made some progress in investigating the likely cause of slowness for some #GNOMECalendar users who have a metric shitton of events to display: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1381#note_2375819
STOP DOING NEW #HARDWARE
* CPUs were not supposed to be idle
* YEARS OF NEXTGEN yet NO REAL-WORLD USE for going higher than SANDYBRIDGE
* Wanna go faster for a laugh? We've a tool for that: it's called #SYSPROF
"Please give me 192 CORES. Please give me INFINITY of BogoMips"—Statements dreamed up by datacenters
LOOK what Silicon Vendors have been demanding your respect for with all the chipsets we built for them
*Points at bunch of single-threaded software*
They've played us for absolute fools
After many more hours of testing and investigation on Saturday night, then three more hours last night to analyze and summarize that discussion's insights, here are my latest findings on the @gnome file manager's "slow cold-loading of the view's contents for folders with many files" performance issue :blobsweats:
https://gitlab.gnome.org/GNOME/nautilus/-/issues/3374#note_2353755
I has the potential to be as fast as Thunar.
I bet it would speed up all views, even search.
#Nautilus #GNOMEFiles #Sysprof #performance #GNOME #Linux #Thunar
The rabbithole investigation of Nautilus' very slow cold-disk-cache folders loading performance continued this week end.
Latest findings here: https://gitlab.gnome.org/GNOME/nautilus/-/issues/3374#note_2345406
#GNOMEFiles #Nautilus #GNOME #performance #Sysprof #benchmarking #filesystems
New hardcore #PDF rendering performance benchmark for #Poppler:
"Jesus Christ it's a #Lyon (map), get in the car!" :blobnom:
That map takes 26 seconds to render with Poppler on #Linux, but only 6 seconds with PDFjs, or 15 seconds with XPDF: https://gitlab.freedesktop.org/poppler/poppler/-/issues/1555
I've profiled the issue on the various Poppler rendering backends, and there are some hypotheses about the slowness. If anyone can help fix this, that would be fantastic.
Finally, an explanation for #GNOMESoftware's slow scrolling when browsing apps! Thanks to @kdwk for finding out that it only happens when the mouse is over the items instead of "in the margin on the side"…
The fact that it is hundreds of times slower, however, was a rather unexpected finding :blobsweats:
I added some #Sysprof performance profiles to this ticket: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2172
I wonder whether it's #GTK, the pixbufs, or something else in the #GNOME graphics stack 🤔
The (un)fortunate side-effect of me attending the @XOrgDevConf this week is that I found a new #GNOMEShell performance issue to report about scrolling workspaces with a touchpad, because I saw what 60fps feels like on @TheEvilSkeleton's AMD-powered laptop and now I cannot un-see this jank on Intel graphics: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7976
