Saturday, June 8, 2013

Beware of the gcc 'ext' directory?

Profiling, I found myself confronted with a C++ program that was dying the death of one thousand calls to malloc and free, courtesy of STL. I set out to see if I could use the STL allocator model to improve the situation.

Off I went to the GCC documentation: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt04ch11.html. Here I found a pool allocator, but it is documents to have miserable multithreaded performance. In any case, for one of the cases I had in mind, the even cheaper array_allocator seemed to be just the ticket. I could state a reasonable upper bound for the space I needed, and this would just about eliminate overhead.

The documentation here is, to say the least, minimal. I was bemused to discover that googling didn't yield much else -- just a bug report from my old friend Scott McKay. I didn't need to do what he did that hit the bug, so I proceeded. I was bemused, however, by the lack of discussion.

Problem 1: the array allocator doesn't work with basic_string. The basic_string code assumes that the allocator can be respecialized to return a 'char *'.  The array allocator won't do that; it results in a compilation error.

As it happened, the string in question was only used inside the private methods of a class, and the class didn't need many string functions at all. So I switched it to being a vector.

That found me problem 2: The very first attempt to insert into the vector threw a bad_alloc, due to some  other bug. At this point, I threw up my hands, and changed over to the simple use of arrays.

So, there seem to be two morals of the story. If no one is posting anything about 'X' on the internets, it perhaps implies that no one is using 'X'. And if no one is using 'X', there is probably a good reason.



No comments:

Analytics