0

I ran a small test using C# using struct and class ... executed a simple method on each (console app) with WriteLine and used System.Diagnostics.StopWatch to measure.

My expectation was struct would be faster, but the results show them to be almost identical in performance.

There has been a lot of emphasis on stack vs. heap with the provision that heap has more processing overhead ... I've been fairly vigilant with my code thinking the stack is where I want to be if design construct fits.

So is there something else happening in the Virtual Execution System (aka CLR) that's doing some optimization that trivializes the stack and heap?

I must admit, I've never actually thought about testing this before, maybe I just need a more complex test to really see the difference?

Thoughts?

Cheers, Rob.

trincot
  • 317,000
  • 35
  • 244
  • 286
Rob Ainscough
  • 576
  • 5
  • 14
  • 1
    When talking about performance, context matters. Without seeing your code, it's impossible for us to tell you why you didn't get the results you expected. Your statement that "heap has more processing overhead" is true, but only to a point. It's not accessing items on the heap that costs, but rather allocating (and, to some extent, de-allocating) memory. If you want anything like a reasonable answer, you'll have to show us your code. – Jim Mischel Jan 03 '20 at 06:43

1 Answers1

0

Premature optimisation.

You don't choose heap/stack based on speed. You pick it based on how much memory you're going to need. The only extra overhead is the time to allocate/deallocate heap memory but that is trivial in the grand scheme of things.

You've already spent more time on this than it needs :-)

John3136
  • 28,809
  • 4
  • 51
  • 69
  • Have to disagree with you there, the stack should be much faster regardless of memory consumption. Maybe this is a CLR thing and results would be different with unmanaged C++? Or is it CPU cache? – Rob Ainscough Dec 31 '19 at 22:43
  • 1
    You think there are 2 physical types of memory and one is faster than the other? "Stack" is the same memory, just that the "system" lets you have part of it as a stack. Perhaps this is a better answer? https://stackoverflow.com/questions/24057331/is-accessing-data-in-the-heap-faster-than-from-the-stack – John3136 Dec 31 '19 at 22:46
  • @RobAinscough "The stack should be much faster regardless of memory consumption." Not true at all. What makes you think it should be so? – Jim Mischel Jan 03 '20 at 06:46
  • No, well actually yes, there are several levels of physical memory that operate at different speeds, L1 cache, L2 cache, L3 cache, RAM, VRAM, etc. etc. ... but for clarity I'm talking "access" ... this article suggest stack is faster because allocation is done at compile time vs. heap which is allocated at runtime: http://net-informations.com/faq/net/stack-heap.htm a "bit slower" ... I'm assuming because the stack is LIFO where-as heap allocation takes more work to allocate and track ... perhaps the issue boils down to memory fragmentation over time? – Rob Ainscough Jan 04 '20 at 00:07