Memory Allocation Issue with Tween.Custom Method

[KinanGH98]

Hey everyone,
I'm encountering a memory allocation issue when using the Tween.Custom method. Here's a snippet of the code:

private void StartTween()
{
Profiler.BeginSample("Tween Custom 1");
Tween.Custom(this, 0, 1, duration: .5f, (target, value) => target.SomeMethod(value));
Profiler.EndSample();
}

private void SomeMethod(float newFloat)
{
// Empty method.
}

Despite SomeMethod being an empty method and using the free allocation way of calling the tween, it seems that memory is still being allocated. I've attached a screenshot showcasing the memory allocation associated with this code.

One thing to note is that the allocation only happenes the first time the above Tween.Custom is called. After that every time its called it will not allocate any memory.

Those benchmarks are done on a standalone build outside the Unity editor.

Now the real story is that I've wrote the code above just to see whats going wrong with my original code which is this:

Tween.Custom( borderGradient.color1, healthProfiles[health].Color, duration: .5f, onValueChange: (newColor) =>  borderGradient.color1 = newColor);

I'm calling this tween 3 times in my code (with a little variation in each call) without knowing that it allocates 5KB of memory every time I call it.

I've tried changing the above code and the results still the same:

Tween.Custom(this, borderGradient.color2, healthProfiles[health - 1].Color, duration: .5f, (target, newColor) => target.borderGradient.color2 = newColor);

I'm unsure why memory is being allocated in this scenario and how I can optimize it.
Thanks in advance for your help!

[KyryloKuzyk]

Hey Kinan, thanks for a great thread!

The GC Alloc topic is complicated, and I should write a detailed article on GC memory allocations in PrimeTween. Let me break down your question into multiple answers:

1. Mono.JIT entries come from the Mono's Just-In-Time compilation. These allocations are inevitable and happen with the Mono backend every time any line of C# code runs the first time. There is no way to prevent them because this is how Mono works. If you want to run any code, Mono should first compile it before running, and this shows in the Profiler. IL2CPP builds doesn't have this.
   To validate this, make an IL2CPP build, attach the Profiler to it, and observe that there are no more Mono.JIT entries.

2. The first time you start any animation, PrimeTween creates a static delegate that animates for that particular animation. This happens only once for each animation and you see a GC.Alloc in the Profiler. This is not technically garbage because static fields are not subject to Garbage Collector.
   To test this, run the Demo and play any animation for the first time and see an allocation. However, there will not be any allocation for any subsequent calls to the same animation.

3. This code allocates GC because the delegate captures the borderGradient variable inside a closure:
   Tween.Custom( borderGradient.color1, healthProfiles[health].Color, duration: .5f, onValueChange: (newColor) => borderGradient.color1 = newColor);
   To prevent an allocation, please see this documentation section: https://github.com/KyryloKuzyk/PrimeTween?tab=readme-ov-file#zero-allocations-with-delegates

4. This is the correct approach that doesn't allocate GC. You'll see a static delegate allocation the first time you play this animation, but after that, no allocation should happen. Could you please double-check that?
   Tween.Custom(this, borderGradient.color2, healthProfiles[health - 1].Color, duration: .5f, (target, newColor) => target.borderGradient.color2 = newColor);

[KinanGH98]

1- Thanks, I wasn't aware of this info.
2- Actually this is the main problem, the frame drop is happening only the first time the tween is called, after that, there are no frame drops (I know the cause of this issue now).

I've tried the Tween.Custom with the target parameter and tested it, the results are like you've said, an allocation happens the first time its called, after that no allocations.
I think the practical way is to cache the tween by calling it at Awake or Start method when the game starts, This will prevent the allocation from happening mid game.
Thank you very much for your explanation.

[KyryloKuzyk]

Actually this is the main problem, the frame drop is happening only the first time the tween is called, after that, there are no frame drops

Most likely, you're experiencing the frame drop because you're running the game with Profiler. Profiler greatly influences the actual game performance, especially in the Deep Profile mode.

PrimeTween's delegate allocation is extremely small and it should not be noticeable in production builds, so there is no need to cache or pre-warm anything.

[KinanGH98]

The frame drop is happening on a standalone build without any profiling.

PrimeTween's delegate allocation is extremely small and it should not be noticeable in production builds, so there is no need to cache or pre-warm anything.

Thats right on most occasions, but in my situation I'm calling that tween 3 times on the same frame (with some variation in each call), producing 15KB of total garbage. Now thats not fatal amount of garbage but in some situations when the pc is running some other tasks, the frame drop is noticable, so I'm trying to get the most free-allocation ways possible, or at least allocating memory when the user won't notice (pre-warming on Awake or Start methods).

Anyway, the problem is now fixed.
Thanks a lot.