Reproduction Steps
In this test place, Animation_Memory_Test.rbxl (52.6 KB), I created two almost identical local scripts that differ by only one line. The only difference is that one calls ContentProvider:PreloadAsync({animation}) before playing the animation and the other does not. They’re called Test_Preload and Test_No_Preload respectively. They create an animation track, load it onto a Humanoid, play it, and then unload it.
-
Preload large animations (or other large assets) using ContentProvider:PreloadAsync() (Test_Preload)
-
Destroy and clear all related references and instances
-
Monitor memory usage
-
Repeat without using ContentProvider:PreloadAsync() (Test_No_Preload)
Expected Behavior
Ideally, we could control what happens with preloaded assets following the preload. Potentially by manually unloading them through ContentProvider or having thresholds depending on asset type, size, or defined re-usability.
Actual Behavior
When an array of assets is passed to PreloadAsync it is never removed from memory even after the assets are destroyed and all other references to them are cleared. I assume this is intentional for caching purposes but becomes a crash point when preloading especially large animation files as animations no longer being used continue to exist in memory indefinitely. Preloading such animations is especially necessary during production style events, like concert experiences, for users with slower internet connections and lower end devices, but in this case they are unlikely to be reused and hold up a large amount of system resources unnecessarily leading to crashes affecting these users.
When preloading it clears about half of the initial memory used for each animation but never all of it. Below is a sample of the numbers that the “Animation” memory tag read (via Stats Service) while loading and playing three different animations during testing.
With Preload
(Idle → Loaded → Unloaded)
-
0mb → 639mb → 329mb
-
329mb → 1076mb → 713mb
-
713mb → 1521mb → 1128mb
No Preload
(Idle → Loaded → Unloaded)
-
0mb → 311mb → 9.5mb
-
9.5mb → 383mb → 20mb
-
20mb → 424mb → 31mb
In the first case memory for animations alone peaked at 1521mb then dropped down to 1128mb where it stayed until the session ended. Being able to free that memory when necessary would allow us to still preload assets but not have to worry about them being held in memory indefinitely.
Issue Area: Engine
Issue Type: Crashing
Impact: High
Frequency: Constantly