Closed L1Q closed 2 years ago
That's a good idea! It could also help debugging issues like #25.
I'm changing the code to include more debug info but meanwhile I was curious about the performance problem you are reporting.
Would you have a look at the output of strace protonutils list -c
, please? You should be able to see where it hangs.
protonutils
does not read the contents of Steam library folders from the filesystem, so the total size of the installed games does not affect the speed of the output (for list for example). My libraries currently contain about 800G of games and protonutils list
takes 0.65s uncached (and 0.06s cached). protonutils
currently is single-threaded and takes what it can get from 1 CPU.
I also added debug logging, now, in #29.
You can test by running the binary from CI: https://github.com/nning/protonutils/suites/6695814930/artifacts/254295941
Run like DEBUG=1 ./protonutils list -c
v1.6.1 silently takes 100% of a single core for an extended period of time.
Are you running list
or list -c
(with or without appid/name caching)?
Are you running list or list -c (with or without appid/name caching)?
I am normally running list
and ge update
with no additional arguments, both hang silently as originally mentioned.
Here I ran them for multiple minutes with strace:
strace-protonutils-list--c.txt
strace-protonutils-ge-update.txt
I also added debug logging, now, in https://github.com/nning/protonutils/pull/29.
DEBUG=1 ./protonutils list -c 2> debug.log
:
debug.log
Yep, steam.ParseTextConfig(/home/l1q/.local/share/Steam/config/loginusers.vdf): 728 B
is the only message that shows up (same for both list -c
and ge update
).
Hopefully, this helps troubleshoot the hanging problem, not sure if the logging itself is of much use so far.
Thanks for the logs! This actually pinned it down to an infinite loop when trying to translate Steam user names that are not included in loginusers.vdf
to 64 bit Steam IDs.
Please re-test with the following binary from CI: https://github.com/nning/protonutils/suites/6697714136/artifacts/254433872
v1.6.1 silently takes 100% of a single core for an extended period of time. I suspect it is related to the bigger steam library on a spinning hard drive (48 games taking ~550 GiB), but can't confirm anything. Would highly appreciate a
--verbose
flag, preferably applicable to every command.The following info would be useful: