It's because test 2 isn't creating a new p variable at each iteration.
IMO only one (the same address) variable is used loop after loop.

The test3 have to go from bytes to bytes setting value to 0 which makes it really use NUMBER_OF_ALLOCATIONS variables.

Edited

You're asking the compiler to do something you're not writting him to do.
Test1 or test3 are the way to go if you want new variables.

Edit for your edit: i'ts because it's not even an optimisation: the compiler see you want to use only array[given_position] and replace it by the address.

I think a decompilation would show that.

I'm okay with memory leaks, since it'll all get freed after the program terminates.

I can't think of a way to constantly allocate new items on the stack in a loop.

Those functions look insanely useful for stack-based dynamic allocation. As soon as the function returns, they disappear. Like some neat form of garbage collection.

It's a pity they're non-portable.

GCC has supported VLAs via extensions since forever as well.

I suspect the technique used to measure the results isn't valid either... This is sort of a waste of time regardless since you can't make generalizations about such things, but if you really wanted to benchmark things you should be using an existing profiling technology to measure the results external to your actual program(s)...

The "time" is a global value acquired by the system at its leisure. It would be subject to complex scheduling from the kernel, etc. You aren't strictly measuring the code that you intend to measure.

The fact that your test cases are all in the same program also suffers from the fact that the overhead of cases isn't properly separated. As was pointed out, in some case, the setup is done outside of the "benchmark" process. You'd probably be better off writing 3 separate programs independently and comparing the results of those.

Of course, most important is knowing what to compare and why. I'm not an expert on the subject so I'm not trying to assert any kind of failure in your technique. I'm just pointing out that in my experience it's a flawed approach to the problem. I was hoping others with more experience testing the validity of the approach would jump in. Machines are complicated and the specifics of how a piece of code performs are subject to use case specifics. If you really want to understand what happens then you should be testing multiple toolchains and probably examining the assembly or machine code output. Of course, that would probably be a huge waste of your time if your aim isn't to master optimization of low-level machine code so I suppose the emphasis on my post is to ask what you're trying to achieve. The question you're asking just doesn't seem all that valid. You're welcome to ask it and test it, but I think that you should research your method more to make sure that your results are reliable before placing too much weight on them...

While we're getting nitpicky, your code looks like a bastardization of C and C++. Which would be more or less OK if you were writing C++ and using C within it, but your header includes are all C specific... Aside from the new allocation_type the program is essentially C, and allocation_type is just an alias in this case for double, which has no special constructor semantics, etc. You could have just as easily used malloc and done it in C. Calling it C++ seems like you haven't quite figured out that they're distinct languages and it generally matters which style you use in C++ (i.e., if you do things C style in C++ there's a style to it, and there's a reason for it; and if you really want C then just use C).

A fun story that I learned of recently... Many years ago a collection of Perl developers came up with a concept that they thought would speed up certain kinds high-level of operations. It took them 10 years to work out all of the edge cases and blah blah blah. Initial benchmarks showed a minor improvement of about 15% in what they aimed to improve upon. Small, but it could add up. It took a while for somebody clever to compare with benchmarks of before the work began. It turns out that they slowed a core feature down by 15%, and the "speed up" managed to bring this one edge case of use back to par with what they started with. In other words, the other 85% of uses for this feature were slower and they gained nothing. They weren't focused on testing what mattered so their initial benchmarks ended up being misleading and useless and even harmful and until somebody had an honest thought the delusion fooled them all.

Well, yes, as bamccaig suggests indirectly, gettimeofday isn't a really good high precision timer, and benchmarking and profiling are not so easy as you'd expect. For gcc, gprof may be useful to you.

That being said, I think this point of performance of different storage types in C is normally nothing to worry about. Rather use the memory allocation strategy that fits your design. A static buffer is best for long term storage of a fixed amount of data, malloc'ed space is best for long term storage of dynamic data that can grow and shrink, and automatic storage (the "stack") is best for temporary, short lived data.

profiling really isn't a great benchmark, in fact its a really bad one.

Thanks! That one I got was straight from a stack overflow. Hence to C-ness.

True! I just think it's neat to be able to explicitly do a stack-based method as a kind of brain teaser. What are the implications? What are the benefits. And so on.

Bam: Actually, I really don't care that my tiny program is full of C and C++. That's not the point. This isn't a live project. It's a tiny test to confirm what I've read about relative allocation speed.

That's why I'm using longer tests and running the program multiple times to average the results.

Static pools are great for using the "shells" of destroyed objects over and over, as well as when all objects are tied to a common "death." It's very easy to allocate a static pool (ala Boost for example), run a game round, and have everything die without memory leaks regardless of whether or not destructors are called. You could easily tie the concept to garbage collection that runs per "scene".

That's kind of the point. If you had zero overhead for finding the position of your next object to allocate (I haven't written allocation code yet), then all that would be left would be writing to that location. My code is actually typedef'd to allow me to use large structures as well as simple primitive types, so that write speed can be a significant amount of the time.

Keep in mind, this test isn't done, I just started it and wanted some feedback. But it's more-or-less confirmed what all the theory I've read has stated, it just quantified it a little. I was surprised about the fake static pool being so long, however, since I was expecting it to be faster than stack memory. Since a stack still requires modifying the stack, yet this literally is using no management at all and is still slower.

Yeah! That's one of the many SO threads I was reading that inspired me to make a quantitative test to see how much faster they really were.

Also,

http://wyw.dcweb.cn/static_mem_pool.htm

and

http://www.boost.org/doc/libs/1_57_0/libs/pool/doc/html/index.html
http://www.boost.org/doc/libs/1_57_0/libs/pool/doc/html/boost_pool/pool/pooling.html

Once I had the proper allocations setup (hence this thread), I was going to move toward some more realistic use-cases such as random access, allocations, and deletes.

That idea of "always hot in the cache" is pretty interesting. I don't really know if there's any benefit to having a design pattern that takes exploits that (optimization before profiling is obviously bad!). But it's interesting to try and force yourself to think in away that all accesses are done on a stack level. Which might be identical or related to RAII--I'm not clear enough on the idea to know yet.

Thanks for your insight so far, everyone!

Wow, I keep hearing over and over companies (Google!*) that ban use of C++ exceptions. Makes me feel better about not liking them.

Whenever I suggest on Reddit I don't like them, everyone calls me a moron. But I have a feeling Reddit is more populated by CS undergrads than actual professionals.

*Though, many people refute that guide.

[edit] I know there's a reply below, but man, I really have to restate how awesome that video is with Mike Action. It starts a little slow but really gets good.