Don't allocate small objects about boost-histogram

[HDembinski]

If you want to run benchmarks to check this claim of bad heap performance, be careful to do it correctly. On Linux, allocating an array of PODs with new will be "very fast", because the OS does not actually do anything yet. The actual allocation only happens when you write to this memory.

[henryiii]

Adding boost::optional adds a dependency, and this is something that should not happen "often", so paying a small cost should be okay. But it should be looked into.

[HDembinski]

It will hurt in timeit benchmarks of the fill performance in Python. fast-histogram is 25x faster than numpy for small arrays because it doesn't allocate a second array for the bin edges.

[HDembinski]

Some allocations were removed, but there are more to go.

[henryiii]

Keep in mind that making Python objects makes small allocations too, and also pays a little extra cost as well in Python bookkeeping.

[henryiii]

Immediately reading everything into C++ structures, then working on those (possibly without the GIL) would probably be the fastest way to work. (Thinking of Python arguments here, but could be applied to other places with small allocations possibly) I'm not against adding boost::optional if it helps the design, as well. At the moment I'll be focusing on things needed for 0.5, feel free to work on it though!

[HDembinski]

Keep in mind that making Python objects makes small allocations too, and also pays a little extra cost as well in Python bookkeeping.

Creating new Python objects, yes. I avoid creating new Python objects. Creating a py::None costs nothing, since there is only one allocated instance of None in a Python program anyway.

[HDembinski]

Immediately reading everything into C++ structures, then working on those (possibly without the GIL) would probably be the fastest way to work.

I don't believe this is true and you would sacrifice single-thread performance.

[HDembinski]

I think this can be closed. I haven't noticed anything lately.