Brutal reality check: class vs struct is not a style debate. It is a behavior + memory-cost decision. If you still think struct = stack and class = heap, you are already optimizing the wrong thing.
This module fixes two silent performance traps. First: value vs reference semantics. A struct is copied. A class can be shared through a reference. That changes both behavior and cost. Second: string garbage. A harmless-looking UI text path can allocate every frame and wake up the garbage collector when you least want it.
Start here: stop asking stack or heap? in the abstract. Ask what is copied, what is shared, and where this specific use case ends up stored. The SharpLab memory-graph walkthrough in this module makes that visible fast: a struct can stay self-contained, while a class keeps a pointer on the stack and the real data behind it.
Then profile one hot text path. In the lesson sample, naive string addition hits about 412 B per frame. Interpolation reduces some of that. A careless StringBuilder is not automatically better. A lower-allocation path can cut that sample much harder.
Warning: the answer is not always use structs, and it is not always use StringBuilder. Big structs copied through tight loops can hurt. Strings with boxing, interpolation, or temporary concatenation can still leak garbage into hot code. Dogma is what gets you in trouble here.
CEO/Producer translation: this is how you tell a real memory risk from programming folklore before the team burns a week rewriting the wrong thing.
The members-only module is the full step-by-step playbook: the SharpLab stack/heap walkthrough, the real copy-vs-share rules, the string-allocation benchmarks, boxing and interpolation caveats, and the practical fixes that stop hidden GC debt before it shows up as stutter.
Unlock the full members-only module and stop paying invisible memory taxes for myths, copies, and garbage you did not profile.
In this module:
Join the membership to unlock the full module, audio, and resources.