2

Consider the next piece of code

class foo {
public:
  void f() { 
    char buffer[1024];
    memset(buffer, NULL, 1024);
    read_some_input_to_buffer(buffer, 1024);
  }
};

class bar {
public:
  void f() {
    memset(_myPrivateBuffer, NULL, 1024);
    read_some_input_to_buffer(_myPrivateBuffer, 1024);
  }

private:
  char _myPrivateBuffer[1024];
};

Will bar::f() work faster than foo::f()? As I see it, the buffer already exists in bar, so the compiler won't allocate memory for it on the stack when the function is called? Or am I wrong and the memory is already allocated before foo::f() is called as well?

gsamaras
  • 66,800
  • 33
  • 152
  • 256
Pilpel
  • 2,931
  • 3
  • 25
  • 57
  • 2
    Allocating memory on the stack takes no time. – Barmar Jun 10 '17 at 00:55
  • 1
    When you call a function, the stack pointer is adjusted by the amount of space used for all the local variables. All this does is change the amount that it's adjusted by, but it has to do the adjustment with or without the local variable. – Barmar Jun 10 '17 at 00:56
  • 3
    This is a classic case of useless premature optimization. Have you used a profiler to determine that the memory allocation is a bottleneck that affects the performance of your code? If the answer is *No*, then you're wasting time and should move on to real issues. – Ken White Jun 10 '17 at 00:57
  • 1
    It would be different if the local variable were a class object with a constructor, then it has to call the constructor and destructor. But for POD, there's no overhead at all. – Barmar Jun 10 '17 at 00:57
  • Note that the `bar` method means that every object will allocate that memory, even if the `foo()` function is never called. If you have an array of `bar` this memory will be multiplied. – Barmar Jun 10 '17 at 00:58
  • 1
    @KenWhite Why would I profile this? I'd rather ask a more general question on stackoverflow and get a good answer that will actually teach me. What do you mean by "real issues"? I want to better understand how my code runs – Pilpel Jun 10 '17 at 00:59
  • 1
    Member variables should be used for data about the object that really needs to persist between calls, not for temporary data like this. – Barmar Jun 10 '17 at 00:59
  • What he means is: [Premature optimization is the root of all evil](http://c2.com/cgi/wiki?PrematureOptimization) – Barmar Jun 10 '17 at 01:00
  • @Barmar What's POD? – Pilpel Jun 10 '17 at 01:00
  • @Pilpel Plain Old Data: https://stackoverflow.com/questions/146452/what-are-pod-types-in-c – Barmar Jun 10 '17 at 01:01
  • As I said, because it's time you're wasting on premature optimization (worrying about the performance of something that you've not identified as being a performance issue). *How can I change this code to be faster?* when you don't specifically know it needs to be faster is a total waste of time. If a profiler hasn't identified it as a problem, move along to a productive use of your time. – Ken White Jun 10 '17 at 01:01
  • @KenWhite I now better understand your answer, but still I didn't post this saying "hey I want my code to run faster so I'm asking you guys if there's a difference in these examples", but more like "how does the compiler treat these different pieces of code" – Pilpel Jun 10 '17 at 01:03
  • The title says *Is it faster*, and your post says *Will this be faster than that*. I responded to what you wrote. If you were asking something else, then you should have asked something else. I can't read your mind to see what you *meant* to ask. I can just read what you wrote. – Ken White Jun 10 '17 at 01:38

1 Answers1

1

is it faster if I store them in the class itself?

No.

so the compiler won't allocate memory for it on the stack

Allocating memory on the stack is equivalent to moving the stack pointer. And more important, stack is always hot, the memory you get is much more likely to be in cache than any far heap allocated memory. Read more in Which is faster: Stack allocation or Heap allocation.


PS: Be careful not to become a victim of premature optimization.

gsamaras
  • 66,800
  • 33
  • 152
  • 256