Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Profile-Guided Optimization (PGO) benchmark report#2385

zamazan4ik started this conversation inIdeas
Discussion options

Hi!

As I have done many times before, I decided to test the Profile-Guided Optimization (PGO) technique to optimize thegitui performance since the project (according to the README file) somehow cares about its runtime speed. For reference, results for other projects are available athttps://github.com/zamazan4ik/awesome-pgo . Here are my benchmark results.

This information can be interesting for anyone who wants to achieve more performance with the application in their use cases.

Test environment

  • Fedora 40
  • Linux kernel 6.10.12
  • AMD Ryzen 9 5900x
  • 48 Gib RAM
  • SSD Samsung 980 Pro 2 Tib
  • Compiler - Rustc 1.81.0
  • gitui version:master branch on commit90a226927b226f33736f6c5cad150c895008a92a
  • Disabled Turbo boost

Benchmark

For benchmark purposes, I use the proposed in the "Benchmarks" section way - opening the Linux kernel repo. I usethis repo withmaster branch and87d6aab2389e5ce0197d8257d5f8ee965a67c4cd commit. The benchmark is the following:

  • Open GitUI on the "Log" tab and wait for the commit process to finish. Measure the time between the application start (I open it from the "Log" tab) and the parsing finish points

For PGO optimization I usecargo-pgo tool. Release binary is built withcargo build --release command. The PGO training binary is built withcargo pgo build, PGO optimized binary - withcargo pgo optimize build.

taskset -c 0 is used for all commands for reducing the OS scheduler's influence on the results. All measurements are done on the same machine, with the same background "noise" (as much as I can guarantee), and multiple times (at least 3 times each binary).

Results

I got the following results:

  • Release: 15.7s on average
  • PGO optimized: 13.3s on average

The results are consistent across runs. At least in this simple benchmark scenario, I see measurable improvement. Maybe it will be useful to know if we aim peak performance for the app.

Further steps

At the very least, the gitui's users can find this performance report and decide to enable PGO for their applications if they care about its performance in their workloads. Maybe a small note somewhere in the documentation (the README file?) will be enough to raise awareness about this work. Another way - try to figure out the root cause of performance differences between PGO and non-PGO gitui versions, and, probably, try to tweak the library sources a bit more - however this way also requires some time to analyze the resulting LLVM IR/assembly differences between them.

Also, Post-Link Optimization (PLO) can be tested after PGO. It can be done by applying tools like LLVM BOLT. However, it's a much less mature optimization technique compared to PGO.

Thank you.

You must be logged in to vote

Replies: 0 comments

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Ideas
Labels
None yet
1 participant
@zamazan4ik

[8]ページ先頭

©2009-2026 Movatter.jp