[Dev Log] FFI 최적화 2, 마샬링이라는 전보붙이는 수준에 느려터진 병목 개선

1. C++ is Powerful, but Cold as Ice

In the last post, we witnessed the horror of Coroutines slaughtering the main thread. The solution was crystal clear: stop running your architecture like a toxic sweatshop that works its single star employee to death. You need to fire the useless middle managers and actually balance the workload across all cores. In plain dev terms, this means taking the heavy math operations out of C# and offloading them to the rest of the CPU cores via C++ Native Plugins.

Honestly, if you're a junior and you've made it this far, give yourself a pat on the back. FFI optimization is a nightmare to debug, and technically, your game will still "run" even if you don't do it. So, you Google a quick tutorial, slap [DllImport] at the top of your script, neatly pack up 10,000 object data points using some friendly struct-marshalling technique from a blog post, throw it over to C++, and wait for your framerate to skyrocket.

Except reality isn't that generous.

The technique above is just a way to move data from C# to C#—it is NOT performance optimization. If you fire up the Unity Profiler with high hopes, you'll see the main thread graph spiking like a wall-street crypto pump that you desperately wish was your personal stock portfolio. C++ is supposed to be multithreading the math, so why in the hell is this happening?

2. The Marshalling Tax: Shipping Hard Drives via Overnight Courier

The problem lies in the "logistics system" used to pass data between two completely different worlds: C# (Managed) and C++ (Unmanaged).

The naive data-passing method most beginners use (Value Copy) is like an outdated, on-premise company shipping physical hard drives by courier. When C# asks C++ to process 10,000 coordinate vectors, the system individually serializes every single piece of data into a C++ compatible struct, allocates new memory, tightly bubble-wraps it, and ships the package across the border into C++ territory.

C++ then unboxes the package, does the math, repackages the results into a brand-new box, and ships it right back to C#. This brain-dead packaging and delivery process is called Marshalling. The actual math took 0.1 milliseconds, but you just burned 10 milliseconds loading and unloading delivery trucks at the warehouse (The Marshalling Tax). As the boxes pile up, the Garbage Collector (GC) goes absolutely ape-shit.

3. The Architect's Fix: Cloud S3 and Zero-Copy Pointers

Stop frantically packing boxes. When modern IT infrastructure needs to share massive amounts of data, do we send hard drives on a motorcycle? Hell no. You upload the data to the cloud (AWS S3) once, and just text the recipient a URL link.

Your memory architecture should follow this exact cloud model. This is the Zero-Copy paradigm.

In C#, you allocate one giant array holding 10,000 data points exactly once. This is your cloud storage. Instead of packaging and sending the data to C++, you simply hand it a single memory pointer: "Hey, the data is at memory address 0x1A2B. Walk over there, read it, and overwrite it directly."

A memory pointer is a meager 8 bytes (on 64-bit systems). Whether you're passing ten data points or ten million, the toll fee is permanently capped at 8 bytes.

4. Overcoming C#'s Scare Tactics: unsafe and fixed

As you know, C# was birthed by Microsoft. Frankly, even if I'm being generous, it’s hard to call it a "great" language. It’s essentially Java wearing a C costume.

I bring this up because moving data from a native language like C++ to C# is as terrifyingly unstable as moving data from C++ to Java. So, Microsoft jammed a safety lock onto the C# compiler called the unsafe keyword—like putting a child-proof cap on a bottle of bleach. And if you dare to unlock it, the compiler starts screaming at you like you're a toddler running around holding a jug of open bleach.

As real developers, we need to ignore these cheap threats from the compiler.

This brings us to fixed. Unity's Garbage Collector is like a spoiled houseplant, wandering around reorganizing memory whenever it feels like it. If you hand C++ a cloud address and the GC suddenly decides to relocate that memory block mid-operation, C++ will end up writing into thin air. fixed is how you handle this. Here is the code:

// A Zero-Copy FFI call with ZERO bytes of data movement (Marshalling)
private unsafe void ProcessNativeBatch()
{
    // fixed: Puts a chokehold on the Garbage Collector and screams,
    // "Don't you dare touch or move this array until I get back from C++!"
    fixed (PathJobData* ptr = _nativeJobArray)
    {
        // Simply toss the starting memory address (Pointer) to the C++ function. (Sharing a URL)
        ComputePathsBatchNative(ptr, _nativeJobArray.Length, Time.time);
    }
}

The moment this short block executes, the C++ thread pool directly accesses the cloud (shared memory), unleashes every available CPU core, and overwrites 10,000 coordinates at lightspeed. C# doesn't need to copy arrays, nor does it need to wait for a return value. It simply reads the updated data right where it left it.

5. Conclusion

Optimization isn't a cheap trick to shave off a few lines of code. It’s low-level logistics engineering—designing where data lives, how it flows, and who owns it.

Will you remain an on-premise hard-drive courier, or will you step up as a cloud-era architect controlling 10,000 objects with a single 8-byte pointer URL? The choice is yours.

I have a lot to say about FFI, but I will stop here. Next, let's look at ways to optimize and prevent Unity from betraying our trust.