Having major performance issue with a game load time.

[jarrard]

I have a odd case where a game takes 10-20minutes to LOAD (is fine once loaded) under windows.

Takes 1minute under Linux.

The game is RogueTech which is a mod for BattleTech, it is just driving me insane and makes it unplayable as you need to restart this game regularly. It's being run on a NVME with zstd compression set to 1, runs super fine under Linux.

Is compression cause MAJOR performance issues under winbtrfs? what could be going on?

PS. This MOD/GAME does a HUGE amount of IO file caching and checking upon game-start.

[maharmstone]

If you take an uncompressed copy of the game, how does that perform?

[jarrard]

I'll try to test that out tomorrow.

The game performs quite well once loaded, its just the initial loading phase that is remarkably slow.

[maharmstone]

Thanks. I'm interested to know what it's doing...

[jarrard]

Thanks. I'm interested to know what it's doing...

Any recommendations on how I can easily and quickly decompress a folder? Maybe turn off compression on the entire drive, copy files elsewhere and then back again? (I'm doing this now)

I know there is a file/folder properties for compression but I suspect that doesn't work, also it seems to not be recursive.

[jarrard]

I'm noticing a few files couldn't copy, asif their corrupt. (Copying to same NVME in different folder, NOT moving)

I noticed random file corruption when moving from Windows (WinBTRFS) to Linux on active drives that run games on.

Wondering if that could be part of the cause also?

Is scrub meant to detect these corrupt files? I don't think it does.

Additionally it doesn't explain why the game still worked; by all means these corrupt files should have broke the game (such as the main heavymetal dlc package being one of them, a critical component)

[jarrard]

Folder uncompressed, repaired by steam, moved back to original position, no compression shown on folder.

Problem seems to persist, so compression is NOT the issue. There is likely some windows component being done by the modtek script/mod loading tool that winbtrfs doesn't like.

Again under Linux load-up time doesn't exceed 1minute, under Windows it is 5+ minutes! (this was not a issue on NTFS)

UPDATE: I noticed my drive has 36334 unrecoverable errors. Not sure HOW this happened and hoping winbtrfs isn't the cause. Will boot into Linux and perform some repairs (removal of bad files) and then come back to windows to retest.

UPDATE2: After repairs and making sure nothing was corrupt for the game being tested here. Performance issues remain for game startup. Other then completely deleting this partition and download all files again, I don't know what else I can do.

Really don't have the time to do all that since I'm on a slow connection.

[maharmstone]

Okay, thanks for this. I'm going to give it a go myself and see if I can reproduce it.

You say this is for a mod for BattleTech - how does the base game perform?

[jarrard]

Base game I believe is fine.

https://discourse.modsinexile.com/t/rogue-tech/134

Launcher will update itself and game mod folder once you point it to correct locations.

UPDATE: Most other games seem fine with only microstutter hitching. If you can figure out what's causing RogueTech(BattleTech mod) to have this loading slowdown it may help go a long way to speeding up performance elsewhere since it is the rare case of a game being greatly affected in load times.

[jarrard]

This driver is NOT compatible with Baldurs Gate 3. Causes loads of crashing. Moved game to a ntfs, now works perfectly.

[maharmstone]

Thanks @jarrard. Yes, you're right, it segfaults. I'll have to work out what it's doing immediately before the crash.

Possibly a race condition, as when I ran procmon to trace it, it seemed to work alright.

0:039> .ecxr
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for bg3_dx11.exe - 
rax=0000000000000000 rbx=0000000000000000 rcx=0000029a2ef8f8fc
rdx=000000000000003f rsi=000000000299dd28 rdi=0000000000000000
rip=00007ff6eb5e10d7 rsp=000000ca4dcaeb90 rbp=000000ca4dcaec18
 r8=0000029a2ef8f8fc  r9=0000000000000000 r10=0000000000000017
r11=000000ca4dcae990 r12=0000000000000301 r13=0000000000000680
r14=0000029a2c57edb0 r15=0000029a2e5a0ae0
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
bg3_dx11!AK::WriteBytesCount::Clear+0x65cd7:
00007ff6`eb5e10d7 48037058        add     rsi,qword ptr [rax+58h] ds:00000000`00000058=????????????????
0:039> kv
  *** Stack trace for last set context - .thread/.cxr resets it
 # Child-SP          RetAddr           : Args to Child                                                           : Call Site
00 000000ca`4dcaeb90 00007ff6`eb5e90f8 : 00000000`00000000 000000ca`4dcaec71 00000000`00000000 00000000`0299dd28 : bg3_dx11!AK::WriteBytesCount::Clear+0x65cd7
01 000000ca`4dcaebc0 00007ff6`eb5e49d9 : 00000000`00000000 00007ff6`eb612b86 00000000`00000011 000000ca`4dcaf180 : bg3_dx11!AK::WriteBytesCount::Clear+0x6dcf8
02 000000ca`4dcaecd0 00007ff6`eb5e08aa : 00000000`00000000 00000000`00000000 00007ff8`00000000 000000ca`4dcaedd1 : bg3_dx11!AK::WriteBytesCount::Clear+0x695d9
03 000000ca`4dcaed50 00007ff6`eb5e057a : 000000ca`4dcaeea0 00007ff6`eb5d7dfe 00000000`00000000 00000000`00000000 : bg3_dx11!AK::WriteBytesCount::Clear+0x654aa
04 000000ca`4dcaee30 00007ff6`eb5e1486 : 000000ca`4dcaefb8 ffc00000`00000000 000000ca`4dcaeec8 00000000`00000000 : bg3_dx11!AK::WriteBytesCount::Clear+0x6517a
05 000000ca`4dcaef00 00007ff6`eb54652c : 000000ca`4dcaef90 000000ca`4dcaf060 ffc00000`00000000 00007ff8`97eb986b : bg3_dx11!AK::WriteBytesCount::Clear+0x66086
06 000000ca`4dcaef60 00007ff6`eb4d2488 : 0000029a`2eb697b0 00007ff8`97906e00 000000ca`4dcaf36c 00000000`0000004d : bg3_dx11!AK::WriteBytesMem::Count+0x761acc
07 000000ca`4dcaf030 00007ff6`eb39262a : 0000029a`2eb697b0 000000ca`4dcaf36c 000000ca`4dcaf230 00000000`00000000 : bg3_dx11!AK::WriteBytesMem::Count+0x6eda28
08 000000ca`4dcaf110 00007ff6`eb0980a5 : 00000000`00000010 000000ca`4dcaf600 00000000`00000001 000000ca`4dcaf230 : bg3_dx11!AK::WriteBytesMem::Count+0x5adbca
09 000000ca`4dcaf1d0 00007ff6`eaff92f4 : 000000ca`1bd00021 00000000`00000000 000000ca`4dcaf350 0000029a`38d1a4c0 : bg3_dx11!AK::WriteBytesMem::Count+0x2b3645
0a 000000ca`4dcaf200 00007ff6`eaff9708 : 00c00001`000001a9 000000ca`4dcaf2b9 000000ca`4dcaf808 00007ff6`eaff8b8f : bg3_dx11!AK::WriteBytesMem::Count+0x214894
0b 000000ca`4dcaf230 00007ff6`eaff94b5 : 000000ca`4dcaf808 000000ca`4dcaf788 0000029a`48cf5e00 0000029a`48cf5e00 : bg3_dx11!AK::WriteBytesMem::Count+0x214ca8
0c 000000ca`4dcaf320 00007ff6`eaff9299 : 0000029a`48cf5e00 0000029a`48cf5e00 00000000`00000000 0000029a`48cf5e00 : bg3_dx11!AK::WriteBytesMem::Count+0x214a55
0d 000000ca`4dcaf8c0 00007ff6`eaff4e38 : 0000029a`48cf5e00 0000029a`48cf5e00 0000029a`38f46100 00000000`00000000 : bg3_dx11!AK::WriteBytesMem::Count+0x214839
0e 000000ca`4dcaf8f0 00007ff6`eb0f9e01 : 0000029a`48cf5e00 0000029a`48886580 0000029a`38d95b00 00007ff6`eb12ca4c : bg3_dx11!AK::WriteBytesMem::Count+0x2103d8
0f 000000ca`4dcaf920 00007ff6`eb098fc8 : 0000029a`48cf5e00 00000000`00000000 0000029a`48883520 00000000`00000003 : bg3_dx11!AK::WriteBytesMem::Count+0x3153a1
10 000000ca`4dcaf950 00007ff6`eb1d0cc7 : 0000029a`2c9bb870 0000029a`38f46100 00000000`00000000 0000029a`48883520 : bg3_dx11!AK::WriteBytesMem::Count+0x2b4568
11 000000ca`4dcaf9a0 00007ff6`eb255337 : 00000101`01f00434 0000029a`48cd2dd8 0000029a`48e42b00 00000000`00000001 : bg3_dx11!AK::WriteBytesMem::Count+0x3ec267
12 000000ca`4dcaf9e0 00007ff6`eb623876 : 0000029a`2c7aeec0 0000029a`48e42b58 0000029a`48e42b30 0000029a`4771d760 : bg3_dx11!AK::WriteBytesMem::Count+0x4708d7
13 000000ca`4dcafa40 00007ff6`eb5d7fb4 : 0000029a`2eb33810 ffffffff`fffffffe 0000029a`2eb577a0 00000000`00003538 : bg3_dx11!AK::WriteBytesCount::Clear+0xa8476
14 000000ca`4dcafa90 00007ff6`eb5d81c7 : 0000029a`2eb33810 0000029a`2eb33a20 0000029a`2eb577a8 00000000`00000000 : bg3_dx11!AK::WriteBytesCount::Clear+0x5cbb4
15 000000ca`4dcafad0 00007ff8`99e97034 : 00000000`00003538 00000000`00000000 00000000`00000000 00000000`00000000 : bg3_dx11!AK::WriteBytesCount::Clear+0x5cdc7
16 000000ca`4dcafb10 00007ff8`9a142651 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14
17 000000ca`4dcafb40 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21

[jarrard]

Well somehow I was able to get into game and play for 15mins or so.

Also a very odd behaviour I noticed was with Vulkan API when changing the VIDEO settings it would lockup the screen but you could hear it in background. When I moved it to NTFS this did not happen. Very weird issues indeed!

[maharmstone]

Like I said, I'm fairly sure it's a race condition: the game's making assumptions based on timings that hold true for NTFS but not Btrfs. The stack trace I posted above is almost certainly a Larian bug: it's calling a function which returns a pointer, then dereferencing it without checking that it's not NULL.

[DocMAX]

Very slow loading here too. Forza Horizon 5.

[jarrard]

I also noticed something interesting with a external USB HDD I have formated as btrfs under Windows when I go to save files to it, OFTEN it does this thing where the internet and browser halts for a few seconds.

I thought this to be maybe the HDD parking and needing to re-power up but it happens often within 1minute of each save to the drive and this does not occur under Linux.

I've noticed this under Brave and Firefox. It could be related to this driver adding some sort of IO overhead issue.