I think the biggest GC-related performance benefit of value types isn’t that you can allocate them on the stack, since a generational GC will easily eat up those allocations. It’s so that more *long-lived* data can become pointer-free and not scanned at all.
-
Show this thread
-
e.g. consider a particle simulation with “class Particle { Vector pos; Vector vel; }”. If Vector is a pointer type then the GC will have to scan every Particle. But if Vector is a value type, then GC can avoid looking inside Particles entirely. Now imagine you have 1M particles…
2 replies 6 retweets 31 likesShow this thread -
Of course in Java you would often optimize this as “class Particle { float pX, pY, pZ, vX, vY, vZ; }”. But then you’re in the bad situation of having to choose between having nice methods on vectors and performance. Value types let you have both.
5 replies 4 retweets 41 likesShow this thread -
Replying to @pcwalton
Has any runtime made per-type decisions on representing particular types as values versus boxes to maximize ? In C# the rule is that structs are always values, objects are always boxes.
5 replies 0 retweets 3 likes -
Replying to @TimSweeneyEpic
I don’t know of one. I’ve thought about such optimizations, but it seems hard, because the semantics of value vs. reference types are so different. Plus it would have to be a global optimization, which has problems with separate compilation, etc.
2 replies 0 retweets 0 likes
This might be a good candidate for a linter that tells you when your class could be a struct instead.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.