DEV Community: Danial Jumagaliyev

Building in Public while Job Hunting: My January Dev Update

Danial Jumagaliyev — Sun, 25 Jan 2026 05:58:48 +0000

Between building a versioned Redis implementation and getting screened by AI recruiters, January has been... a lot.

Let's begin with the cool new stuff.

New Projects

mdspace - easily paste and share markdown files.
- I built this tool because I got tired of sharing markdown files with my peers. Either the formatting is not properly supported by the messenger or the text/file is too big. With mdspace - you paste the contents or upload the file and directly get a share link for viewing it.
- The tool also supports reviewing/commenting via highlighting a line in the file itself. Overall a nice personal problem I've solved for myself and I'm sure others can benefit from.
verdis - a versioned Redis.
- I'm co-developing this Go project - an implementation of Redis with versioning as a core feature: key value store with multi-version concurrency control (MVCC) and historical data access.
- Ideal for applications that need audit trails, collaborative editing, or the ability to query data as it existed at any point in time.
ShaRPC - robust RPC (Remote Procedure Call) framework for C# projects.
- Since 2021, I've been dealing with RPCs in multiplayer game systems and backend services. But a thought recently came to my mind - does C# have a good RPC framework?
- Sure, there's gRPC but codegen is a build step, not compile-time. There's SignalR, a great alternative which meshes well with ASP.NET Core, but still comes with its own drawbacks - supporting only JSON serialization and the WebSocket protocol, with runtime codegen. A full comparison chart between frameworks is here, if you're curious.
- ShaRPC is built different. It's transport-agnostic, with source generator-based code generation, designed for Unity and .NET Core interoperability. As a result, you get a high-performance RPC framework for all kinds of C# projects.

Open-Source Contributions

Made some pretty hefty pull requests to big repositories this month. Some are yet to be finalized... 💀

But I can proudly say that I'm an active contributor to the open-source community. Here are some of the repositories I've been resolving issues for:

Next AI Draw.io (19.4K+ stars, TypeScript)
Repo Health (100+ stars, TypeScript, active maintainer)
ReMinecraftPE (400+ stars, C++) - this one has been a fun (nightmarish) experience.

Why Open-source?

I'm pretty sure I answered this in my last podcast video, but I just think it's the best way to grow as a developer. You not only contribute to a project, you learn, you communicate, you collaborate. You research the repository, what technical decisions were made and why.

To fellow beginner software devs out there - I'm telling you, it's an easy way to get real "hands-on" experience, familiarize, experiment with new tech stacks. If the project is big enough, where it's actively maintained, has real users, and your pull request gets merged - consider that your code in production.

The community is mostly welcoming, with developers being eager to help. Heck, I have several open-source projects out there - if someone tackles an existing issue in them, I would only be down to get it fully resolved and help if needed.

Now, while I've been productive on the code front, I've also been seeking new job opportunities. And as you may already know, or have heard, the job market isn't great.

The Job Search

I can't say much but describe how daunting it is to apply to jobs these days and scroll through LinkedIn. Bunch of AI slop posts, fake comments... It has truly become a misery of a place.

Fortunately, I am at least able to get a few interviews going for me right now, but I am literally competing with a 100 more developers. So sometimes I can't help it but wonder if I'm just wasting my time. It feels like a rat race...

I hate it.

The state of AI usage isn't making it any easier. I've been invited to interviews with no people present - just an AI with a robotic voice that you talk to. I would rather talk to myself, than have an LLM form an opinion about me.

To my fellow job seekers

Hang in there. Times are tough. Don't think that just because you didn't pass an interview, you weren't qualified. Even if you're skilled enough, you might not be the right fit attitude-wise. That's why it's important to stay resilient and persistent.

What's next?

Expecting to drop one more thing this month - potentially a technical writeup on one of these projects.

If any of this resonated with you, feel free to reach out to me. Always happy to connect with fellow devs navigating this mess together.

Stay determined <3

[Boost]

Danial Jumagaliyev — Mon, 19 Jan 2026 18:13:54 +0000

Communication Beats AI Slop in Open Source

ElshadHu ・ Jan 19

#webdev #programming #ai #opensource

Nobody was interested in my portfolio, so I made everyone play it instead.

Danial Jumagaliyev — Mon, 05 Jan 2026 04:16:41 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

Controls	Keyboard & Mouse
Move	A/D or Left/Right keys
Jump	Space key
Emoji Window	Q key
Zoom In/Out	Mouse Scroll

Alternatively available on my website: www.danqzq.games

🎮 Challenge: Can you find all the collectible cards scattered around the map? Drop a screenshot in the comments when you find them all!

In the next 5 minutes, you'll see why I spent 3 years building my own networking stack just to make my portfolio weirder.

About Me

For the record, this is what my portfolio used to be:

Working in a creative field, a boring scrollable page just didn't feel right anymore. I wanted a way to actually show what I can do, not just list it. So I took my rusty old portfolio site and turned it into an online multiplayer game world, where I can pretty much do ANYTHING I want.

I'm a game developer who believes that technology should be engaging, interactive, and boundary-pushing. This portfolio represents years of experimenting, failing, and building, from simple backends to complex multiplayer systems.

The Portfolio in Question

The embedded application above is a fully functional cross-platform multiplayer game that serves as my interactive portfolio. Instead of scrolling through a conventional website, visitors can explore my work through gameplay while seeing live updates of my:

Latest YouTube videos
GitHub activity and contributions
Indie game projects
Open-source projects
Random "Dan Facts of the Day"

There are also collectible cards placed around the map, each revealing pictures and information about me and my career.

And there's even a special button that literally lets you call me into the world if I'm available - the kind of stuff you can't really do with a traditional portfolio.

How I Built It

The Stack

Game Engine (client-side): Unity 6 (WebGL build with mobile support)
Networking: Dan.Net - My custom Go + WebSockets networking stack
Deployment: Google Cloud Run (2GB memory, 2 CPUs)
AI Assistant: Google Antigravity for workflow optimization
APIs: YouTube Data API, GitHub API
Server: Custom Node.js HTTP server with gzip handling

Why I Built My Own Networking Stack

Here's the thing: I didn't use some off-the-shelf multiplayer solution. Everything from the core gameplay logic and statistics displays down to the networking layer was built by me. Yes, including the entire networking stack: Dan.Net.

FUN FACT: I drew quite a good amount of art assets as well, using Aseprite. All apart from some random PNGs for the skins and the tile-set art. The music is the Toyota Corolla 2008 theme. Please do not question the choice of music ;)

This portfolio is actually the culmination of a 4 year journey into multiplayer systems:

2021: I started with Photon Engine, made some games, but felt like I was just calling functions without understanding what was happening under the hood.

2022: I went down the rabbit hole. I experimented with Python/Flask, built my Leaderboard Creator tool (now one of the highest-rated on itch.io), tried PHP, moved to Node.js and WebSockets. By late 2022, the idea for Dan.Net was born.

2023: The grind. I remember spending three straight days debugging a multithreading race condition. Just me, the debugger, and this cursed bug. When it finally worked, those three days became some of the most rewarding of my life.

2025: Finally, I pushed Dan.Net to a stable, production-ready state. Ready to power real projects.

How the Multiplayer Actually Works

All players connect to a central server hosted in the cloud. Here's the simplified flow:

Room System: Players are able to create or join rooms using a room name. You can think of rooms as "player pools" or "matches" in a game, where players are able to gather together.

Event-based Networking: When something important happens (player joins, picks up a card, changes their skin), that player sends a "buffered event" to the server. When the player reacts with an emoji, that's sending a "direct event". The server then broadcasts it to everyone else who needs to know about it (the other players in the room).

Stream-based Networking: Every few milliseconds, each player sends their current position to the server. The server aggregates all positions and sends back updates about where everyone else is on the map.

Under the hood, there's interpolation, latency compensation, bandwidth optimization - all that fun stuff :)

But at its core, it's about keeping everyone's view of the world in sync.

Deploying to Google Cloud Run (The Hard Part)

Unity's WebGL builds use gzip compression, which sounds great until you try to deploy them. The challenge: browsers need specific HTTP headers to decompress these files correctly, and Cloud Run doesn't set them by default.

The Solution: I built a custom Node.js HTTP server that:

Detects .gz files and sets Content-Encoding: gzip headers
Maintains correct MIME types for WebAssembly, JavaScript, and data files
Handles CORS properly for cross-origin requests
Serves the 36MB build efficiently with proper caching

This was one of those problems where Google Antigravity saved my time by a lot, helping me debug header configurations and optimize the server setup.

Where Google Antigravity Helped Me Most

I used Google Antigravity throughout development, particularly for:

Dan.Net Improvements: Refining how the Unity client communicates with my Go backend, especially around WebSocket connection handling and state synchronization.

Cloud Run Debugging: Troubleshooting why my Unity build wasn't loading correctly (it was the headers). Antigravity helped me understand the relationship between Unity's compression, HTTP headers, and browser requirements.

API Integration: Implementing the YouTube and GitHub APIs securely without exposing keys or creating vulnerabilities. The dynamic boards that show my latest videos and contributions wouldn't work without proper API setup.

What I'm Most Proud Of

1. Building Dan.Net from Scratch

Creating my own Go-based networking solution and successfully integrating it with Unity for cross-platform multiplayer. This demonstrates full-stack capabilities spanning from low-level networking protocols to high-level game development in my journey. Check out Dan.Net to see the implementation.

2. Breaking the Portfolio Mold

This isn't just about showing what I've done - it's about showing what I can do. A true portfolio shouldn't be a static page; it should be an experience that reflects your skills and personality. When I said I can do ANYTHING I want here, I meant it.

3. Real-Time, Living Portfolio

The dynamic boards update automatically based on my activity - my latest YouTube videos and recent GitHub activity, so the world always feels alive and current. The "Dan Fact of the Day" changes daily. This means visitors always see fresh content without me manually updating anything.

4. Cross-Platform Multiplayer Experience

Thanks to Unity 6's improved web support, the game works seamlessly on desktop, mobile, and web browsers. The entire experience is powered by Dan.Net, demonstrating not just front-end skills but also understanding of networking protocols, state management, distributed systems, and backend architecture.

5. Interactive Features You Can't Do Elsewhere

You can hit a button that calls me into the world. I'll join if I'm available. ;)
Or the collectible cards that reveal information as you explore.

These are the kinds of creative features that make this portfolio memorable and engaging.

The Philosophy Behind It

If there's one piece of advice I'd give to anyone, whether you're in a creative line of work or deeply technical, it would be: share your work, and document your journey. Be proud of what you've built and what you're still building. Don't hesitate to put yourself out there.

Here's the thing: we learn by watching each other. When you share your work, the messy parts included - you're giving someone else permission to try. Your story might be exactly what someone needs to take their own first step. Sometimes seeing one person figure it out is enough to make us think "I could do that too."

Nothing you learn ever really goes to waste. It just shows up in the next crazy idea. To me my portfolio is: years of experiments, failed projects, and learning moments all coming together into something I'm genuinely proud of.

Try it out and let me know what you think in the comments! And if you're interested in game development, networking systems, open-source development, or just want to hang out - feel free to reach out to me via my Discord server — I'd love to connect!

Do you want to see more behind-the-scenes content, weird prototypes, and devlogs about this portfolio world evolving over time? Check out my YouTube channel and GitHub!

C# Performance Optimization: Using Span and stackalloc to Eliminate Allocations

Danial Jumagaliyev — Thu, 04 Dec 2025 05:04:46 +0000

Runtime memory handling is a crucial part of writing software, which heavily impacts the performance of your program. I think for every language there comes this layer of responsibility, but how it is delegated between the developer and the language is different.

In the case of using C/C++ - memory allocation is totally under the control of the developer. Whereas in languages like JavaScript, Python, Go, Java, where memory is managed - developers rarely need to worry about where an array is stored in memory, it's the duty of the language's runtime system to decide when to deallocate data that is no longer used. And this is where garbage collection comes into play.

C# (.NET platform) is known for its heavy GC (garbage collection) of dynamic (heap-allocated) resources. The process is straightforward - garbage collection automatically identifies unused memory (garbage) and frees it to be reused, efficiently recycling resources.

This article explores how stackalloc and Span<T> eliminate garbage collection pressure in performance-critical C# code, using real optimization examples from Dan.Net, my Unity networking library. By the end, you'll understand when and how to apply these techniques to reduce allocations by orders of magnitude in hot code paths.

Memory Allocation in C`#`

By default, the data of all reference types (classes, arrays, strings, delegates and interfaces) are allocated on the heap. The references to heap objects, however, live on stack or heap, but value types stay on stack unless boxed (converted into object type):

Location	Storage	GC Impact
Local reference variable	Stack	None (reference only)
Class field reference	Heap	Collected with object
Local value type	Stack	None unless boxed

On one hand, this is amazing. As the developer, you focus more on writing core logic and you get to easily structure your code in meaningful ways; you don't have to care about ensuring runtime safety and clean up dynamic memory resources after use - this job is handled automatically by the garbage collector, which is part of the .NET CLR (Common Language Runtime).

However, this could easily become a recipe for disaster in terms of performance. A developer who isn't familiar with the .NET ecosystem is likely to write code that may look good on the surface - but could be causing unnecessary memory allocations underneath the hood, reducing execution speed as a result.

I, personally, used to make this mistake often when working with .NET in my first few years of building Unity projects. I would receive performance feedback that I was using too many LINQ (Language Integrated Query) statements, which can cause excessive garbage collection, especially in the older .NET versions. In those days, I barely thought about the importance of memory management.

For instance, I would write code like this in a hot path that executed every frame:

// ❌ Allocates multiple enumerators and intermediate collections
var activeEnemies = enemies
    .Where(e => e.health > 0)
    .OrderBy(e => e.distanceToPlayer)
    .Take(5)
    .ToList();

Each LINQ operation allocates an enumerator, and ToList() allocates a new list. At 60 frames per second, this becomes 60 allocations per second per operation, triggering frequent garbage collections that cause frame drops.

Motivation

I was recently enjoying my weekend by reviewing my personal projects, until I decided to look into Dan.Net again. It's my own networking library for Unity, operating over HTTP/WebSockets and prioritizing ease-of-development and cross-platform-ability. I have been experimenting and toying around with it for quite a while now, and made a proper release of it earlier this year on GitHub.

Shortly after its release, I had a friend review it for me and they gave me some honest feedback. There's more to the story that deserves its own article. But in short, I chose to optimize - not out of necessity, but passion. It was working, but not fast enough. The drive for optimizations truly emerged within me, echoing Linus Torvalds' ethos.

With AI producing more code every day, I realized that mastering the fundamentals is key for programmers to truly understand and oversee the systems we build. And this is exactly why I am writing this blog!

After implementing the optimizations described in this article, Dan.Net's per-frame allocation during active network synchronization dropped significantly, from ~2.5KB to under 200 bytes - a 92% reduction. This eliminated GC stalls during 20Hz network updates, maintaining stable frame times even with 50+ networked objects.

About Memory

Stack Basics

The stack holds short-lived data like local variables and method parameters in a LIFO (Last-In, First-Out) structure, with automatic allocation/deallocation on method entry/exit. Access is fast due to its contiguous layout and CPU cache affinity, not because it's "in the cache" - both stack and heap reside in RAM. Value types (structs, primitives) live here unless boxed or embedded in heap objects.

The stack has a limited size - typically 1MB per thread on Windows and 8MB on Linux/macOS by default (these are operating system defaults, not Unity-specific). Unity's stack behavior inherits from the underlying .NET runtime and platform. Exceeding this capacity results in a StackOverflowException.

Heap Basics

The heap manages dynamic, long-lived objects via garbage collection, allowing flexible sizing but with slower access from indirection and GC pauses (periods when unreferenced memory gets cleaned up by the garbage collector). It grows as needed (system-limited), unlike the stack's fixed per-thread quota. As mentioned, this is where referenced types (classes, arrays, etc) reside.

Stack Limitations

To make it more clear, let's represent stack memory's LIFO behavior visually:

Stack (capacity: 6)
(empty)
(empty, next insertion goes here)
`4` (first to be out, last in)
`3`
`2`
`1` (last to be out, first in)

After two more insertions, this stack would become full. Assuming no deallocation occurs - the next allocation attempt would lead to a stack overflow. Real stack memory in C# manages method call frames, local variables, and return addresses in this LIFO manner, with each method invocation "pushing" a new frame and "popping" it off when returning.

C# History Lesson

C# provides stackalloc for explicit stack allocation of temporary buffers. Over time, its usability and safety have improved significantly with each major C# release, especially since C# 7.2.

The Danger Zone

Initially, stackalloc could only be used in conjunction with the unsafe modifier. Methods can be defined under an unsafe context, which signals the C# compiler "hey, we're about to do something illegal here":

using System;

class Program
{
    static unsafe void Main(string[] args)
    {
        int length = 5;
        // Allocate a block of memory for 5 integers on the stack
        int* numbers = stackalloc int[length];

        // Use pointer arithmetic to access and populate the memory block
        for (int i = 0; i < length; i++)
        {
            *(numbers + i) = i * 10; // = numbers[i]
        }

        // Read the values back using array-like pointer syntax
        for (int i = 0; i < length; i++)
        {
            // Pointer element access operator p[n] is evaluated as *(p + n)
            Console.WriteLine($"numbers[{i}]: {numbers[i]}");
        }

        // Memory is automatically discarded when the method returns
    }
}

To run this code for yourself, you must modify the .csproj file in your C# project to include <AllowUnsafeBlocks>true</AllowUnsafeBlocks> within a <PropertyGroup>. Here's the expected output:

numbers[0]: 0
numbers[1]: 10
numbers[2]: 20
numbers[3]: 30
numbers[4]: 40

As you can see, stackalloc used to be limited to allocating memory for pointers, which made it primarily a low-level, performance-focused feature suitable for advanced developers requiring fine control over memory, similar to variable-length arrays or the alloca() function in C/C++.

If the above-written code seems confusing to you, I highly recommend touching up on pointers and arrays in C, as C# borrows the same logic from there.

When the stack was truly stacking

It's only when C# 7.2 and 7.3 released that stackalloc became usable outside of unsafe contexts, only if the result was immediately converted to a Span<T> or ReadOnlySpan<T>.

// C# 7.2
int[] dataArray = new int[5] {1, 2, 3, 4, 5};
Span<int> dataSpan = dataArray;
dataSpan[0] = 100; // dataArray[0] is modified

// dataArray is now {100, 2, 3, 4, 5}

You can think of spans as "views" that allow access to memory regions like arrays, strings, or stack buffers, making them very lightweight, drastically reducing garbage collection pressure and improving speed in data-intensive code.

Benchmarking Pitfalls: The JIT Optimizer

Before diving into span performance comparisons, it's critical to understand a common benchmarking problem. Modern JIT (Just-in-time) compilers are extremely aggressive about eliminating "dead code" - code whose results are never used. When benchmarking span operations, if you don't actually consume the results, the compiler may eliminate the entire operation, giving you misleading 0.0000 ns execution times.

I encountered this exact issue when benchmarking the span optimizations. The solution is using BenchmarkDotNet's Consumer class, which signals to the compiler that values are being observed, preventing optimization away. Always verify your benchmarks produce realistic non-zero timings before trusting the results.

I wrote these two methods which serve the same purpose - to retrieve top 3 scores from a scores array of integers. I benchmarked these methods using BenchmarkDotNet:

...
// class SpanBenchmark

private const int length = 1000;
private int[] scores = new int[length];

// Constructor to initialize scores array with values
public SpanBenchmark()
{
    for (int i = 0; i < length; i++)
    {
        scores[i] = i;
    }
}

[Benchmark]
public int[] GetTop3Scores_Copy()
{
    // ❌ Traditional: Copy top 3 scores = heap allocation every time!
    int[] top3Copy = new int[3];
    Array.Copy(scores, length - 3, top3Copy, 0, 3);
    return top3Copy;
}

[Benchmark]
public Span<int> GetTop3Scores_Span()
{
    // ✅ C# 7.2: Slice original array = ZERO heap allocations
    Span<int> allScores = scores.AsSpan();
    Span<int> top3 = allScores.Slice(length - 3, 3);
    return top3;
}
...

Results:

BenchmarkDotNet v0.15.8, macOS Tahoe 26.1 (25B78) [Darwin 25.1.0]
Apple M5, 1 CPU, 10 logical and 10 physical cores
.NET SDK 9.0.306
  [Host]     : .NET 9.0.10 (9.0.10, 9.0.1025.47515), Arm64 RyuJIT armv8.0-a
...
| Method  | Mean      | Error     | StdDev    | Gen0   | Allocated |
|---------|-----------|-----------|-----------|--------|-----------|
| ...Copy | 4.0631 ns | 0.0274 ns | 0.0229 ns | 0.0048 |      40 B |
| ...Span | 0.2082 ns | 0.0202 ns | 0.0189 ns |      - |         - |

We can clearly see that the Span<T> approach is allocating no dynamic memory at all, meaning it's completely utilizing the stack within the method. The Gen0 column shows Generation 0 garbage collections per 1000 operations - the copy method triggers GC pressure while the span approach has zero impact.

The Span<T> class comes with a powerful method - Slice, thanks to which the span method is running faster in the first place. See the function specification here.

We can be safe... and go faster?

We are making use of Span<T>, where the spans can be of type ReadOnlySpan<T> since they aren't modified at all. The main usage of ReadOnlySpan<T> is not mainly dedicated to increasing performance, but rather to communicate the fact that the span is fully immutable.

However, after duplicating and modifying the span method (this time using ReadOnlySpan<T> instead of Span<T> as the type) - I noticed there is about a ~20% reduction in execution time, as evidenced by the benchmark results:

| Method          | Mean      | Error     | StdDev    | Allocated |
|-----------------|-----------|-----------|-----------|-----------|
| ...Span         | 0.1880 ns | 0.0266 ns | 0.0273 ns |         - |
| ...ReadOnlySpan | 0.1460 ns | 0.0142 ns | 0.0126 ns |         - |

The performance improvement from ReadOnlySpan<T> comes from compiler optimizations around immutability guarantees. The JIT compiler can eliminate bounds checks and enable more aggressive inlining when it knows the data won't be modified, reducing instruction count and improving CPU pipeline efficiency.

Execution Time Comparison (lower is better)

Array.Copy      █████████████████████████ 4.06 ns
Span<T>         ██ 0.19 ns
ReadOnlySpan<T> █ 0.15 ns
                |
                0     1     2     3     4 (nanoseconds)

Now, this might not seem like a practical example, but imagine a similar case with significantly more function calls and larger array sizes. Would it make sense to allocate extra dynamic resources where avoidable? We'll later dive into more use cases, coming from my own experience.

Syntax Improvements

Moving on to C# 7.3, it came with support for array initializer syntax:

// C# 7.2 and before:
Span<byte> arr = stackalloc byte[3];
arr[0] = 67;
arr[1] = 68;
arr[2] = 69;

// C# 7.3 and after:
Span<byte> arr = stackalloc byte[] {67, 68, 69};

This significantly reduced the verbosity and error-proneness of low-level buffer initialization.

It only got better from here though, as C# 8 introduced stackalloc support in more nested expression contexts, such as inside conditionals or as part of larger expressions:

int length = 1000;
Span<byte> buffer = length <= 1024
    ? stackalloc byte[length]
    : new byte[length];

C# 12 introduced collection expressions, a concise syntax that often compiles to stackalloc for small Span eliminating explicit keywords entirely:

// C# 12: Compiles to stackalloc for small spans (zero heap!)
Span<int> arr = [1, 2, 3]; // Automatic stack allocation

// Same as:
Span<int> arr2 = stackalloc int[3] {1, 2, 3};  // Verbose equivalent

Applying the Knowledge

Now back onto Dan.Net and where the memory optimizations came in. After a first run-through of enhancing the library, I made it fully operate with binary data. Events and streaming data were now being compressed and serialized into a special binary format before sending to the server, and, subsequently, incoming data was being deserialized and decompressed into data to be used on the client.

These processes required dealing with lots of allocation of bytes and bit manipulation for ensuring fast performance, but I was avoiding the memory overhead and focused on implementing the new binary protocol initially. Only at a second glance I took the decision to begin approaching memory optimizations, which involved heap allocation reduction.

Let's take a look at some of those examples:

1. Range Calculations

Below is a code snippet from my Quaternion compression logic, executed every time before sending data of a networked object's rotation

float[] components = new float[4] { q.x, q.y, q.z, q.w };
int largestIndex = 0;
float largestValue = Math.Abs(components[0]);

for (int i = 1; i < 4; i++)
{
    float abs = Math.Abs(components[i]);
    if (abs > largestValue)
    {
        largestValue = abs;
        largestIndex = i;
    }
}

q here is a Quaternion struct parameter, which contains the data of the current rotation of a networked game object. Quaternions represent 3D rotations as four floats, but can be transmitted in just 7 bytes by using the "smallest-three" compression algorithm - since quaternions are unit-length (x² + y² + z² + w² = 1), we can omit the largest component and reconstruct it from the other three, saving 9 bytes per rotation.

The components array is being allocated on the heap. It's only used locally for performing a simple calculation as shown above. So it's safe to convert the array into a stack-allocated span:

Span<float> components = stackalloc float[4] { q.x, q.y, q.z, q.w };

Might seem insignificant, but this function is to be executed at a frequency of 20 Hz. That's 20 times a second, which is 20 memory allocations of 4 floating point numbers -> 320 byte allocation/sec.

And that's just for one network-synchronized game object. What if we had more? In real-time networking scenarios like my library's streaming system, these optimizations matter.

In a similar fashion, I dealt with Quaternion decompression using spans.

2. Performant Chat Command Parsing

I believe this is where Spans truly shine. Consider a multiplayer game built with Dan.Net where players send chat commands at high frequency. Commands like "/say Hello everyone!", "/join lobby-01", or "/trade player123 50" need to be parsed into command names and arguments - and this happens 100+ times per second in active game lobbies.

The traditional string-based approach allocates heavily:

// ❌ Traditional: Multiple string allocations per command
[DanNetEvent]
public void OnSendChatCommand(string message)
{
    // Example: "/say Hello everyone!"

    if (!message.StartsWith("/"))
        return; // Not a command

    // Remove the leading "/" 
    string withoutSlash = message.Substring(1);

    // Find first space to separate command from args
    int spaceIndex = withoutSlash.IndexOf(' ');

    if (spaceIndex == -1)
    {
        // Execute command with no arguments (e.g., "/help")
        return;
    }

    // Split command and arguments
    string commandName = withoutSlash.Substring(0, spaceIndex);
    string arguments = withoutSlash.Substring(spaceIndex + 1);

    // Execute command with arguments
}

Every Substring() call allocates a new string by copying characters. For the example "/say Hello everyone!", that's 4 heap allocations (withoutSlash, commandName, arguments, plus potential string.Empty) per message. At 100 messages/sec, that's 400 allocations/sec just for command parsing.

Here's the span-based rewrite that eliminates all intermediate allocations:

// ✅ Span-based: ZERO intermediate allocations
[DanNetEvent]
public void OnSendChatCommand(ReadOnlySpan<char> message)
{
    // Example: "/say Hello everyone!"

    if (message.Length == 0 || message[0] != '/')
        return null; // Not a command

    // Slice away the leading "/" - no allocation, just pointer arithmetic
    ReadOnlySpan<char> withoutSlash = message.Slice(1);

    // Find first space to separate command from args
    int spaceIndex = withoutSlash.IndexOf(' ');

    if (spaceIndex == -1)
    {
        // Execute command with no arguments (e.g., "/help")
        return;
    }

    // Slice command and arguments - still no allocation!
    ReadOnlySpan<char> commandName = withoutSlash.Slice(0, spaceIndex);
    ReadOnlySpan<char> arguments = withoutSlash.Slice(spaceIndex + 1);

    // Only allocate when storing final results
    var (finalCommand, finalArguments) = (commandName.ToString(), arguments.ToString());

    // Execute command with arguments
}

The span version performs all slicing operations as lightweight "views" into the original string - zero copies, zero heap allocations until the final ToString() calls. The IndexOf() and Slice() operations are pointer arithmetic, making them extremely fast.

Using ReadOnlySpan<char> as a parameter (instead of string) allows callers to pass string slices, stack-allocated buffers, or even substrings without allocation - the method works with any contiguous character memory.

Bonus Optimization

For known command prefixes, you can avoid string allocation entirely by using SequenceEqual for comparisons:

// Check if command is "/help" without allocating strings
if (commandName.SequenceEqual("help".AsSpan()))
{
    ShowHelpMenu();
    return;
}

// Check if command is "/say" 
if (commandName.SequenceEqual("say".AsSpan()))
{
    SayMessage(arguments);
    return;
}

This pattern allows you to handle common commands completely allocation-free by processing spans directly instead of converting to strings.

3. Vector3 Compression Pattern

private static void WriteVector3(BinaryWriter writer, Vector3 v)
{
    writer.Write(BitConverter.GetBytes(v.x));
    writer.Write(BitConverter.GetBytes(v.y));
    writer.Write(BitConverter.GetBytes(v.z));
}

This method converts a 3D vector (a struct containing three floating point values x, y and z) into binary form.

Looks good on the surface, right? Not until you realize BitConverter.GetBytes() returns a heap allocated byte array.

The solution? Stackalloc a buffer of 12 bytes, then explicitly write the Vector3 values into the three 4 byte segments of the buffer, since the values are all 32-bit (equal to 4 bytes) floating point numbers. And we accomplish this with the help of slicing and the BitConverter.TryWriteBytes() method:

private static void WriteVector3(BinaryWriter writer, Vector3 v)
{
    Span<byte> buffer = stackalloc byte[12];
    BitConverter.TryWriteBytes(buffer.Slice(0, 4), v.x);
    BitConverter.TryWriteBytes(buffer.Slice(4, 4), v.y);
    BitConverter.TryWriteBytes(buffer.Slice(8, 4), v.z);
    writer.Write(buffer);
}

There is a Problem

This approach only works in .NET 5.0 and greater, that's when spans began to be adopted in the .NET ecosystem. My library is used on top of Unity.

Unity still mostly targets .NET Standard 2.1, only unlocking the ability to use newer versions of .NET starting from Unity 6. Luckily there is a sub-optimal solution - using conditional compilation, which allows libraries to target multiple platforms while using the most efficient APIs available on each.

#if NET5_0_OR_GREATER
    Span<byte> buffer = stackalloc byte[12];
    BitConverter.TryWriteBytes(buffer.Slice(0, 4), v.x);
    BitConverter.TryWriteBytes(buffer.Slice(4, 4), v.y);
    BitConverter.TryWriteBytes(buffer.Slice(8, 4), v.z);
    writer.Write(buffer);  // Has Span overload in .NET 5+
#else
    writer.Write(v.x);
    writer.Write(v.y);
    writer.Write(v.z);
#endif

Now, when compiled for .NET 5+, this gets zero-allocation stackalloc; any version lower, and it uses the traditional (but still efficient) approach.

Safety Considerations

While stackalloc is powerful, it requires careful usage to avoid crashes and undefined behavior:

Stack Overflow Risks

Never use stackalloc with user-controlled sizes or variable-length inputs. The stack is limited (typically 1MB per thread), and exceeding it causes unrecoverable StackOverflowException:

// ❌ DANGEROUS: User could cause stack overflow
int userSize = GetUserInput();
Span<byte> buffer = stackalloc byte[userSize];

// ✅ SAFE: Guard with size check and fallback to heap
int size = GetUserInput();
Span<byte> buffer = size <= 1024 
    ? stackalloc byte[size] 
    : new byte[size];

Keep Allocations Under 8KB

For cross-platform safety, keep stackalloc sizes under 8KB (8192 bytes). Larger allocations risk stack overflow on platforms with smaller stack sizes:

// ✅ Safe for all platforms
Span<byte> smallBuffer = stackalloc byte[4096];

// ⚠️ Risky on some platforms
Span<byte> largeBuffer = stackalloc byte[65536]; // 64KB

Never Use stackalloc in Loops

Repeated stack allocations in loops don't get "cleaned up" until the method returns, effectively leaking stack space:

// ❌ DANGEROUS: Stack grows with each iteration
for (int i = 0; i < 1000; i++)
{
    Span<byte> buffer = stackalloc byte[1024]; // 1MB total!
    ProcessData(buffer);
}

// ✅ SAFE: Allocate once outside loop
Span<byte> buffer = stackalloc byte[1024];
for (int i = 0; i < 1000; i++)
{
    ProcessData(buffer);
}

Debugging Challenges

Stack-allocated memory doesn't appear in memory profilers or GC diagnostics, making debugging harder. Always profile both allocation counts (heap) and execution time (stack) to verify optimizations work as expected.

Conclusion

Today, stackalloc is a core feature for scenarios where maximum speed and minimum allocation overhead matter, like parsing or serialization. Developers are encouraged to use it with Span<T> to maintain safety, only falling back to unsafe pointer usage for the rarest high-performance cases. These optimizations reduced Dan.Net's per-frame allocation by over ~80% on average, eliminating GC stalls during 20Hz network updates.

When NOT to optimize with stackalloc: Don't prematurely optimize. Use stackalloc only after profiling identifies allocation hotspots. For one-time setup code, IO-bound operations, or methods called <1000 times/sec, the complexity cost outweighs the performance benefit. Always measure with a profiler before and after.

This evolution has made stack-based, high-performance memory scenarios much more approachable, while maintaining C#'s general focus on safety and productivity.

If you're curious about my other works, check out my portfolio website. Dan.Net is open-source on GitHub - contributions and feedback are welcome!