I've read about Small-Object Allocation in "Modern C++ Design". Andrei Alexandrescu argues that the general purpose operators (new and delete) perform badly for allocating small objects.
In my program there are lot of objects created and destroyed on the free store. These objects measure more than 8000 bytes.
What size is considered small? Are 8000 bytes small or big when it comes to memory allocation in C++?
The definition of "small" varies, but generally speaking, an object can be considered "small" if its size is smaller than the size overhead caused by heap allocation (or is at least close to that size).
So, a 16 byte object would probably be considered "small" in most cases. A 32 byte object might be considered small under certain specific circumstances. An 8,000 byte object is definitely not "small."
Usually, if you are going to go through the trouble of using a small object allocator, you are looking to improve the performance of some block of code. If using a small object allocator doesn't help your performance, you probably shouldn't use one.
I certainly wouldn't consider 8000 bytes to be 'small'. Small objects most likely means objects occupying no more than a few hundred bytes - objects amounting to a handful of bytes are going to lead to the biggest problems - however as KennyTM points out this is implementation dependent and some C++ runtimes may well be great at handling small objects.
[...] argues that the general purpose operators (new and delete) perform badly for allocating small objects.
Platform dependent. E.g. on Linux I once benchmarked my homegrown AVL tree with static memory management vs. GNU's std::map which is red-black tree and fully dynamic memory management. To my surprise, std::map sometimes outran my own highly-efficient implementation. And std::map does hazardous amount of small memory allocations.
In my program there are lot of objects created and destroyed on the free store.
Memory management concern is a valid one. In a sense that you should always try to reuse existing resources if possible or avoid creation of temporary copies.
That's if efficiency/CPU performance you are after. If the code is ran rarely, then it is pointless to bother.
These objects measure more than 8000 bytes. What size is considered small? Are 8000 bytes small or big when it comes to memory allocation in C++?
This is pointless question. If your program needs an object taking 8K, then your program needs it. Period.
You should start worry only if you would receive complains that software takes too much RAM or profiler points to the performance bottleneck in memory management. Otherwise, modern memory management is relatively fast and robust.
P.S. I personally would consider 8K to be an average memory allocation size. Not small - not big. But I'm already used to work with programs which on a whim allocate 10+GB on heap. If data set has to be resident in RAM and it is 10GB in size, well, then application has little choice but to try to load it.
The question is not, how small is the object, but, how much memory overhead is invoked by operator new/delete? If your object is more than that, then it's not that small.