[list store] not optimal for building gigantic messages
If you try to accumulate a large list with [list store], reallocation time becomes a major factor on Windows.
Can easily improve realloc times by overallocating using a simple doubling algorithm.
There's already a related "quick-and-dirty" algorithm like that in unpost_printhook to fill in for C++ iostream from matju's original C++ implementation. So we probably want to put an interface in m_memory.c for general use.
However, we'd need to be careful to document this interface as inappropriate for realtime computation. While it can vastly improve average performance it doesn't guarantee worst-case performance. (And in fact better average perf can hide worst-case perf from the user, which is a strange but very real usability problem in soft realtime environments like this.)
In fact, we may consider adding something like [list storeupto 100] to initialize max size to 100 and error out above that. This would avoid realloc altogether and could be realtime safe if we handle gpointers efficiently.