3 ms·
The original benchmark author is just really unclear what they're trying to benchmark. "Class vs struct performance" is meaningless, because performance at what
by mjr00 3y ago
The original benchmark author is just really unclear what they're trying to benchmark. "Class vs struct performance" is meaningless, because performance at what? The first benchmark does nothing, as the article points out. The second benchmark tests the performance of large numbers of object creations; but why is ElementAt even being called in a loop there? It's confusing since it's irrelevant to what actually ends up taking time. If you're benchmarking the time it takes to create the struct/class objects, just write a benchmark that does that and don't include random other code!
And "structs are more performant" isn't even a correct conclusion; they're pass-by-value, so you could construct benchmarks where the copy time outweighs heap memory allocation time, eg constructing a large object once and passing it to a function many times.
- quietbritishjim 3y agoI don't think you've really refuted the parent comment here. But, what you have done, is written a much better blog post than the original article :-)
- mjr00 3y agoI wasn't really trying to refute the parent! I agree that the article author focusing on LINQ making things secretly n^2 is a red herring (though important to know). But the more fundamental problem is the benchmark being very unclear in what it's benchmarking.
- ablob 3y agoIf struct copies are you problem you can always pass it by ref, so even that isn't an easy claim to make.