Large FMOD 2.00.22 Project making PerForce very laggy and slow

Our game project finally updated from FMOD 1.10.04 to 2.00.22. It is a large and old game project with a large number of assets - the Metadata folder contains 24,098 files currently.

After the update, the project still opens very slowly - it takes several minutes to load up the project. After this, Studio remains slow: low frame rate, clicks take a second or two to register. After a few more minutes, Studio finally picks up and works fast again.

Unfortunately it also seems to have made the P4v (PerForce) visual client slow, even if FMOD Studio is not running. I see regular entries like this in the P4v log feed:

p4 have f:\perforce\cata\branch\main\resources\build_win64_post_hashes.bat f:\perforce\cata\branch\main\resources\build_win64.bat {66 more items}
p4 fstat -Olhp //cata/branch/main/resources/intermediate/effects/test/velocity_facing_example.eff {10 more items}
p4 fstat -Olhp //cata/branch/main/resources/.p4ignore //cata/branch/main/resources/extra_options.xml //cata/branch/main/resources/intermediate/sound/studio_project/Metadata/Mixer.xml {65 more items}
p4 have f:\perforce\cata\branch\main\resources\intermediate\sound\studio_project\Metadata\AudioFile\{66d2f8e3-8a97-4a4d-89ea-8bedf3531e4e}.xml {18026 more items}
p4 fstat -Olhp //cata/branch/main/resources/intermediate/sound/studio_project/Metadata/AudioFile/{f195c331-a4e6-486d-90d5-cbedf08412a9}.xml {813 more items}
p4 fstat -Olhp //cata/branch/main/resources/intermediate/sound/studio_project/Metadata/AudioFile/{16113c86-ea4b-485b-b11b-0a2924eaddae}.xml {2074 more items}
p4 fstat -Olhp //cata/branch/main/resources/intermediate/sound/studio_project/Metadata/AudioFile/{d30177e1-ab4f-449a-9300-f412b8e1a6fc}.xml {2059 more items}
p4 fstat -Olhp //cata/branch/main/resources/intermediate/sound/studio_project/Metadata/AudioFile/{7e0edf1f-4540-4e8a-ae4c-b7d72a7bb4bf}.xml {3316 more items}
p4 fstat -Olhp //cata/branch/main/resources/intermediate/sound/studio_project/Metadata/AudioFile/{b9eb141a-7cc8-46c1-917f-82c240719d98}.xml {2145 more items}
p4 fstat -Olhp //cata/branch/main/resources/intermediate/sound/studio_project/Metadata/AudioFile/{1ffda730-a0ba-401c-95d1-f5fda4d80071}.xml {1156 more items}
p4 fstat -Olhp //cata/branch/main/resources/intermediate/sound/studio_project/Metadata/AudioFile/{9e294fc1-d759-4841-ab29-02fa4454d5eb}.xml {5764 more items}
p4 fstat -Olhp //cata/branch/main/resources/intermediate/sound/studio_project/Metadata/AudioFile/{eca971f1-36b0-4347-83de-4225e3e65e6f}.xml {692 more items}
p4 changes -s submitted -l -m 100 -u username //cata/branch/sp_tools/...
p4 changes -s submitted -l -m 100 -u username //cata/branch/staging/...
p4 changes -s submitted -l -m 100 -u username //cata/branch/main/...

The hangs and slowdowns in P4v seem to be associated with these requests.

So … is Studio still slow at handling large projects with a large number of assets? Note: I have set Studio to use Legacy P4 integration, as advised on other threads on the subject.

Firstly, I just want to confirm whether that version number is a typo, and instead you mean 2.02.22, as 2.00.22 is quite old and unsupported.

If you mean 2.02.22, there was a regression with Perforce performance that we are actively looking into now.

If you are indeed on 2.00.22, then you won’t have the 2.02.07 improvements we made to UI responsiveness due to asset verification happening after load.

Are you able to share your project with us? We can take a look into why it’s performing slowly for you.

1 Like

The version is indeed 2.00.22 - we couldn’t use a newer version because newer than v 2.00.22 refused to compile the game’s dialogue wav files on Linux based auto-builders (which, alas, this old but live game is still running). It was an unknown kind of an error that couldn’t be sorted out by your support.

Thanks for the clarification on the version.

I dug up the old support ticket you mentioned, unfortunately we were never able to reproduce what you were seeing. There was something unique about your old Linux setup, running our Windows version of FSBankCL through Wine. We tested most of those parts, even the files you had troubles with, but weren’t able to produce the error you were seeing. If you wanted to look into that issue some more to unblock your upgrading we could probably provide some instrumented build of FSBankCL.

Otherwise, getting back to your performance issues. You mentioned that Perforce Visual Client has started working slowly, even when Studio isn’t running. Was this a once-off or an ongoing issue? P4V is usually pretty quick at rescanning files when they changed, which might be why you are seeing fstats, but I don’t see what could be causing the slowdown after Studio is closed.

To help get a better picture of what is slowing your project load down, can you share the Studio console log from Window → Console → Logging in Studio, after your project has loaded? It should include timestamps for each part of the load process.

1 Like

Seems like the slowdown of the P4v starts when I launch our internal tool launcher-builder utility. That’s when FMOD Studio starts connecting to PerForce.

In the log it shows that Studio repeatedly logs in to PerForce - no errors though, and since Studio checks out and submits files normally, it can’t be the wrong password I presume. (could be, though, since it was updated some time back, I better check that) Also, there is an in-house plugin that has blank-named parameters that’s causing errors on load, but it’s not making repeated attempts at that.

2024-06-27_fmod_studio_project_open_log.txt (32.8 KB)

It continues with repeated login attempts even after I updated the password.

10:04:35 Executing P4 command "login" with "-s" [#253 times]

Thanks for providing the log file, I can see that it’s taking about 3 minutes to load your project. About 2 minutes of that time is spent IO bound loading .xml files. Unfortunately, this is the death by one thousand cuts, lots of small files lead to slower performance. For me at least, Windows cache takes care of ensuring a second load is a lot faster, but this is something we will continue to investigate and improve.

Regarding the comments about P4 command “login”, this is normal, and shouldn’t be a cause of slow performance in P4V. FMOD Studio performs a heart-beat every 5 seconds to keep the status bar at the bottom up-to-date with your connection status.

The main issue you describe, the slow performance of Studio after the project has loaded is a known issue that was corrected in 2.01.16. In tracking the issue and testing, I actually backported that fix to 2.00.22 and it worked. I’d be happy to share that build with you to eliminate this problem if you’re interested?

Hey there, dropping by unannounced.
If you could share that build with us, that would be great!

I’ve attached the build to your FMOD account, you should receive an email with the link to download.

Figured I should give a quick update. We tried the build you provided, and it seems to have improved the performance. So, thanks for the fix :+1: