question: any way of improving the runtimes startup time ?

[ranplayer]

Your system information

• Steam client version (build number or date): Jul 26 2022
• Distribution (e.g. Ubuntu): Arch
• Opted into Steam client beta?: No
• Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

I'm just wondering if there is a way of improving the runtimes startup time. Proton >= 5.13 relies on containerized runtimes, and even on a fast nvme it takes 10-15 seconds to boot a game (native games boot in 1 second or less).

[smcv]

it takes 10-15 seconds to boot a game (native games boot in 1 second or less)

Doing no setup work is always going to be faster than doing some setup work, and Proton also takes time to start up, so native games with no container are always going to be faster to start than Proton games in a container. Sorry, we can't get something for nothing: the time taken to set up the container is part of the price we pay for it working correctly on various different Linux systems. We can't just not do the setup, because then your game wouldn't work (or if not yours, then someone else's), which is worse than having it take time to start.

If it only had to work on Ubuntu of a specific version, maybe it could be faster - but then you wouldn't be able to run it on Arch, and Ubuntu users likely wouldn't still be able to run it in 5 years' time either.

If there was an easy way to improve startup time in general, we'd have already done it - we've done a couple of rounds of speedups already.

10-15 seconds in a "production" configuration on fast NVME SSD does sound a bit slower than I would expect: I'm getting a similar startup time on a not particularly fast magnetic HDD with extra debug information enabled. If you're concerned that startup is taking unexpectedly long, you could try setting the launch options for a game to

PRESSURE_VESSEL_VERBOSE=1 PRESSURE_VESSEL_LOG_WITH_TIMESTAMP=1 STEAM_LINUX_RUNTIME_LOG=1 %command%

and then launch it. With those options, if anything it will be slower than without them, but it will record a log file in .../SteamLinuxRuntime_soldier/var/slr-latest.log which will indicate where the time went (particularly in the lines that mention Profiling:, which I added during a previous attempt to speed it up). If you attach that log or send it as a gist we can see whether anything is taking longer for you than it should be.

[ranplayer]

Hi @smcv . Thanks for the explanation. I'll try these steps you mentioned to check if there is something wrong with my setup.

[ranplayer]

I'm attaching the logs... don't know exactly if there is something wrong slr-app268910-t20221024T175708.tar.gz

[smcv]

One major thing slowing this down is that you have configured your system to have a mixture of English (India) and Portuguese (Brazil):

17:57:08.376833: pressure-vessel-wrap[9725]: D:     'LANG=en_IN'
17:57:08.376841: pressure-vessel-wrap[9725]: D:     'LC_ADDRESS=pt_BR.UTF-8'
17:57:08.376849: pressure-vessel-wrap[9725]: D:     'LC_ALL=C'
17:57:08.376856: pressure-vessel-wrap[9725]: D:     'LC_IDENTIFICATION=pt_BR.UTF-8'
17:57:08.376865: pressure-vessel-wrap[9725]: D:     'LC_MEASUREMENT=pt_BR.UTF-8'
17:57:08.376873: pressure-vessel-wrap[9725]: D:     'LC_MONETARY=pt_BR.UTF-8'
17:57:08.376880: pressure-vessel-wrap[9725]: D:     'LC_NAME=pt_BR.UTF-8'
17:57:08.376887: pressure-vessel-wrap[9725]: D:     'LC_NUMERIC=pt_BR.UTF-8'
17:57:08.376895: pressure-vessel-wrap[9725]: D:     'LC_PAPER=pt_BR.UTF-8'
17:57:08.376902: pressure-vessel-wrap[9725]: D:     'LC_TELEPHONE=pt_BR.UTF-8'
17:57:08.376910: pressure-vessel-wrap[9725]: D:     'LC_TIME=pt_BR.UTF-8'

but the English (India) locale doesn't actually seem to exist at the system level:

setlocale "en_IN": No such file or directory

The container tool compensates for this misconfiguration by creating its own local version of the necessary locales, but this takes about 8 seconds:

17:57:08.770770: pressure-vessel-adverb[9824]: D: Making sure locales are available
17:57:17.453958: pressure-vessel-adverb[9824]: D: Diagnostic output:
setlocale "en_IN": No such file or directory
pressure-vessel-locale-gen: Generating locale pt_BR.UTF-8...
pressure-vessel-locale-gen: Generated locale pt_BR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale pt_BR.UTF-8...
pressure-vessel-locale-gen: Generated locale pt_BR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale pt_BR.UTF-8...
pressure-vessel-locale-gen: Generated locale pt_BR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale pt_BR.UTF-8...
pressure-vessel-locale-gen: Generated locale pt_BR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale pt_BR.UTF-8...
pressure-vessel-locale-gen: Generated locale pt_BR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale pt_BR.UTF-8...
pressure-vessel-locale-gen: Generated locale pt_BR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale pt_BR.UTF-8...
pressure-vessel-locale-gen: Generated locale pt_BR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale pt_BR.UTF-8...
pressure-vessel-locale-gen: Generated locale pt_BR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale pt_BR.UTF-8...
pressure-vessel-locale-gen: Generated locale pt_BR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale en_IN...
pressure-vessel-locale-gen: Generated locale en_IN successfully
pressure-vessel-locale-gen: Generating locale en_US.UTF-8...
pressure-vessel-locale-gen: Generated locale en_US.UTF-8 successfully

17:57:17.454004: pressure-vessel-adverb[9824]: I: pressure-vessel-locale-gen created missing locales
17:57:17.454045: pressure-vessel-adverb[9824]: I: Generated locales in /tmp/pressure-vessel-locales-4D2SU1
17:57:17.454065: pressure-vessel-adverb[9824]: N: Profiling: end (real 8.7s, user 8.3s, sys 0.4s): Making sure locales are available

You can avoid this slowdown in one of two ways:

• Make sure the en_IN locale is available (uncomment it in /etc/locale.gen and run the locale-gen command as root). Also make sure your other configured locale(s) are all available (in your case I think this is just pt_BR.UTF-8), and make sure the en_US.UTF-8 locale is available (some games need en_US.UTF-8, even though ideally they shouldn't).
• Don't set the LANG environment variable to en_IN. Set it to a locale that you do have, perhaps pt_BR.UTF-8, en_US.UTF-8, or the international/standardized English locale C.UTF-8.

[smcv]

Everything else in your log is going quite quickly, so fixing the locale misconfiguration should reduce the startup time cost of the container runtime to about 1 second.

[smcv]

In Steam's Help -> System Information, if you wait for the full report to appear, the locale misconfiguration should be diagnosed something like this:

"locales": {
...
  "en_IN" : {
    "error-domain" : "srt-locale-error-quark",
    "error-code" : 0,
    "error" : "No such file or directory"
  },
...
},

[ranplayer]

It was hard to find which file was setting this wrong LANG=en_IN, and it turned out that the culprit was Plasma -> .config/plasma-localerc. (haven't changed any locale property since Calamares). Anyway... @smcv thank you for your help .The launching process is taking less time indeed.

[smcv]

I think the only thing that can be done about this from the container runtime's point of view would be to have a warning before we do slow things that shouldn't have been necessary. However, the container runtime isn't a GUI (and in any case a GUI popup would be very annoying), and Steam's stdout/stderr generally points to either the systemd Journal or /dev/null.

If pressure-vessel had logged a message something like this to Steam's stdout/stderr, would you have noticed it?

pressure-vessel-adverb[1234]: W: missing locale "en_IN", startup will be slower

[ranplayer]

Well, for technical users like me it would help (and also to add on the issue template something like "Start the Steam client via a terminal and check for errors/warnings"). But for non-technical users, the Steam client could check the container's output and display a warning popup (just an idea... I'm not really good with UX).

[smcv]

The next beta will log missing locales like this:

setlocale "fr_FR.utf8": No such file or directory
pressure-vessel-locale-gen: Missing locale fr_FR.utf8 (found in $LANG)
pressure-vessel-locale-gen: Generating locale fr_FR.utf8...
pressure-vessel-locale-gen: Generated locale fr_FR.UTF-8 successfully
pressure-vessel-locale-gen: Generating locale en_US.UTF-8...
pressure-vessel-locale-gen: Generated locale en_US.UTF-8 successfully
pressure-vessel-adverb[4535]: W: Container startup will be faster if missing locales are created at OS level

I don't think this issue is worth having a GUI popup for: it's relatively rare, and we intentionally generate the locales instead of just continuing without them in order to make games more reliable. If we added GUI error reporting, it would be for fatal errors first and warnings later, but anything we can do in that direction is only going to be understandable by technically skilled users anyway.

[smcv]

The next beta will log missing locales

This has gone out in today's beta. The key thing in SteamLinuxRuntime_soldier/VERSIONS.txt is to have pressure-vessel 0.20221130.0 or newer.

@kisak-valve, I don't think there's anything else to be done on this issue, and the better logging is only a nice-to-have, so I think we can close this already rather than tracking its progress from beta into stable.

[kisak-valve]

Closing per the last comment.