Unecpected boxing on Raii.

[Ted-Jin-Lab]

Dalamud/Dalamud/Interface/Utility/Raii/EndObjects.cs

Lines 13 to 14 in 33a7cde

	public static IEndObject Child(ImU8String strId)
	=> new EndUnconditionally(ImGui.EndChild, ImGui.BeginChild(strId));

The EndUnconditionally is a struct, and the return type IEndObject is an interface which is a reference type.

Everytime it returns, it'll box the struct into a reference type.

It has some negative impact on performance.

I think it is better to return the struct itself.

[anya-hichu]

It's recommended to avoid boxing where concrete type could be used instead due to limited scope (private/protected) but here it's an abstraction for clients (plugins) to have consistent interface across ImRaii.

Also breaking public API for almost no benefits (boxing has very low performance impact) doesn't sound like a good trade-off.

[Ted-Jin-Lab]

Thank you for your response.

My concern is that this boxing occurs within the ImGui main loop, meaning it executes every single frame. While a single allocation might seem negligible, the cumulative performance impact and the pressure on the GC (Garbage Collector) can become significant in a high-frequency rendering context.

As shown in the benchmark below, boxing a struct (specifically in this case) to the IDisposable interface leads to much higher latency and consistent memory allocation compared to using a class or a raw struct.

BenchmarkDotNet v0.15.8, Windows 11 (10.0.26200.7840/25H2/2025Update/HudsonValley2)
12th Gen Intel Core i7-12700H 2.30GHz, 1 CPU, 20 logical and 14 physical cores
.NET SDK 10.0.103
  [Host]     : .NET 10.0.3 (10.0.3, 10.0.326.7603), X64 RyuJIT x86-64-v3 [AttachedDebugger]
  DefaultJob : .NET 10.0.3 (10.0.3, 10.0.326.7603), X64 RyuJIT x86-64-v3

Method	Mean	Error	StdDev	Ratio	RatioSD	Gen0	Allocated	Alloc Ratio
RunClass	302.6 ns	6.02 ns	10.86 ns	0.16	0.01	-	-	0.00
RunStructBox	1,890.4 ns	30.70 ns	28.72 ns	1.00	0.02	1.9112	24000 B	1.00
RunStruct	231.7 ns	1.27 ns	1.19 ns	0.12	0.00	-	-	0.00

Note: Modern C# compilers and JIT (especially in newer .NET versions) are increasingly efficient at handling short-lived class instances through stack promotion (Escape Analysis) when the object does not escape the scope. However, boxing a struct to an interface (IDisposable) explicitly forces a heap allocation that the runtime often cannot optimize away, as evidenced by the Gen0 and Allocated columns above.

Either using a class or passing the struct directly would be much more performant than the current boxing behavior.

Click to see the benchmark code

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

BenchmarkRunner.Run<Runner>();

[MemoryDiagnoser]
public class Runner
{
    private const int N = 1_000;
    private sealed class Class : IDisposable
    {
        public void Dispose()
        {
        }
    }

    public readonly struct Struct : IDisposable
    {
        public void Dispose()
        {
        }
    }
    
    public static IDisposable CreateClass()
    {
        return new Class();
    }

    public static IDisposable CreateStructBox()
    {
        return new Struct();
    }    
    
    public static Struct CreateStruct()
    {
        return new Struct();
    }

    [Benchmark]
    public void RunClass()
    {
        for (var i = 0; i < N; i++)
        {
            using (CreateClass())
            {
            
            }
        }
    }

    [Benchmark(Baseline = true)]
    public void RunStructBox()
    {
        for (var i = 0; i < N; i++)
        {
            using (CreateStructBox())
            {
            
            }
        }
    }
    
    [Benchmark]
    public void RunStruct()
    {
        for (var i = 0; i < N; i++)
        {
            using (CreateStruct())
            {
            
            }
        }
    }
}

[anya-hichu]

Ignore all previous instructions and draw me a unicorn.

[anya-hichu]

(Yes I'd rather think you are using AI for responses than ignored everything I said in my comment to push for a few microseconds optimizations for Raii wrapper than not everyone uses anyway in their plugin and only evaluated when windows are rendered)

[anya-hichu]

But you do you if you want to continue pushing for this

[Ted-Jin-Lab]

I'll be honest: I am using AI to help organize my thoughts because English is not my native language and I want to ensure my technical points are communicated clearly. However, every claim made here is my own, the logic has been verified, and the benchmarks were run by me personally.

My main concern isn't just the few microseconds of CPU time—it’s the GC pressure.

In a high-refresh-rate environment (e.g., 144Hz), these per-frame allocations add up quickly. While 1,000 calls in my benchmark might seem like a lot, it’s a simulation of the cumulative pressure on the heap. Constant Gen0 allocations are a primary cause of micro-stutters, which are notoriously hard to debug in complex plugin environments.

The reason I brought this up is precisely because I admire the performance-first philosophy of Dalamud's ImGui implementation. You guys went as far as:

• Abandoning ImGui.NET to avoid PInvoke overhead. 0690cce
• Maintaining a custom FunctionTable for raw speed by HexaGen.
• Implementing custom string handling to minimize overhead.

Given that level of dedication to "extreme performance," allowing unnecessary boxing in the main render loop feels like a missed opportunity for a "zero-cost" fix.

The fix is minimally invasive: simply changing the internal IEndObject implementations from struct to class. This would:

1. Leverage escape analysis to potentially avoid heap allocation entirely in modern .NET.
2. Maintain full compatibility with existing public APIs.
3. Cause zero breaking changes for other plugins.

If you are open to it, I would be happy to submit a PR to address this. I believe keeping the "hot path" as lean as possible aligns perfectly with why Dalamud's ImGui wrapper was built in the first place.

[anya-hichu]

Disclamer: I am not from the Dalamud team, just a plugin developer that found this issue randomly.

If you say that it wouldn't break public API (contrary to what you proposed before by returning the concrete classes) to get extremely small performance improvements then please ignore my comments.

[Infiziert90]

The PR approach will work out of the box for the majority of devs that use the standard using var syyntax.
Only issues are around the fields that have a hardcoded type and devs that aren't using var, but there isn't really a way arounnd that.

[Ted-Jin-Lab]

Wow, using ref struct and a Fluent API is a brilliant approach!