steamutil: Optimise get_steam_app_list

[sonic2kk]

Overview

This PR makes some optimisations to steamutil#get_steam_app_list. In my endeavours to see if there is anywhere the startup time for ProtonUp-Qt could be improved, I managed to discover a very small optimisation we can make.

These tests were performed with Python 3.10.17 running in a virtual environment on endeavourOS on a Ryzen 3700X CPU.

Implementation

The main optimisation comes from avoiding repeated dictionary lookups. We lookup the same values inside of our loops, so instead we can store these values and re-use them so they aren't fetched multiple times.

Benchmarks

These tests were done using time.perf_counter. The first commit keeps the timing in place, so you can check out this commit and benchmark independently.

These tests were conducted on endeavourOS on a Ryzen 3700X CPU.

First Run

On a fresh boot of my PC before running python3 -m pupgui2, execution takes significantly longer on main and this PR. I have not included this figure at time of writing as I will need to reboot my PC to verify the speedup.

main	This PR
TBD	0.361s

Subsequent Run

I ran ProtonUp-Qt 10 times on this PR, and 10 times on main.

main	This PR
0.188s	0.176s
0.191s	0.154s
0.231s	0.157s
0.184s	0.153s
0.191s	0.143s
0.231s	0.150s
0.231s	0.176s
0.220s	0.137s
0.207s	0.175s
0.231s	0.167s

The longest execution time on main was 0.231s. The fastest time was 0.184s. The longest execution time on this PR was 0.176s. The fastest time was 0.137s. With this PR, no runs apart from the first run of ProtonUp-Qt took longer than 0.2s in my testing during development and also while benchmarking for this PR.

Future Work

This is... a very minor speedup. But a speedup nonetheless! The main bottleneck from my tests is update_steamapp_info. This is where the 3-4 second startup time comes from on my PC (and longer on handhelds like the Steam Deck). This is probably the "main" area for optimisation, but it isn't as straightforward as the speedups we have in this PR. So I recognise this PR is a small optimisation in the grand scheme, but I hope it can still be considered :-)

As another anecdotal note, I did a test the other day with Python 3.13. It offers a significant speedup in overall execution speed including opening time, opening in about 2-3 seconds instead of 3-4 seconds on my machine. This is something else we can consider when applying updates. Anecdotally, Python 3.12 was slower in my test.

---

As always, all feedback is appreciated! I could be mistaken or naive with how I've tested the speedups too, so I'm very happy to discuss and give feedback.

Thanks!

[DavidoTek]

Thanks!

I agree that even small speedups are a good thing to have!

As another anecdotal note, I did a test the other day with Python 3.13. It offers a significant speedup in overall execution speed, including opening time, opening in about 2-3 seconds instead of 3-4 seconds on my machine. This is something else we can consider when applying updates. Anecdotally, Python 3.12 was slower in my test.

Okay, that is good. We have to use the Python version which is shipped with the Flatpak, but once that is updated, we should automatically get the performance gains (that does not include the other packaging formats of course, we need to look into the AppImage at some point then...)

I noticed that the behavior was changed slightly: Previously, the app would not be added if appmanifest_path exists and appmanifest_install_path does not exist. With this PR, the app is not added if appmanifest_path does not exist. Is there any impact? I assume that the previous version assumed that appmanifest_path would always exist.