Roy Emek wrote:
Iâ?Tm using boost-regex library, and Iâ?Tm running into multi-threading scalability issues. When tested on a machine with several CPUs, my performance tests show improvement of about 60-70% when moving from a single thread to 2 threads.
60-70% doesn't sound too bad to me ?
Question 1: Is anyone aware of this problem? Is there a known solution?
From some testing weâ?Tve done, it seems that the cause of the scalability issue is problematic implementation of std:allocator. This is a known issue on some operating systems (e.g., Solaris 8). Some of the boost::regex classes (e.g., match_results) accept a user-defined allocator. However, as far as I can understand thereâ?Ts no way to completely override the use of std::allocator.
Question 2: is there a way to completely prevent boost / regex from using std::allocator? If no, can such a capability be added?
Actually it used to be there but I was asked to remove it :-( The question you need to ask is which part of the regex lib is causing problems, there are three main areas that use memory allocation: 1) Regex construction: uses std::basic_string and other STL classes along with shared_ptr etc etc, there's no way to change the allocator here. However, the question you need to ask is "do my threads need to construct regexes at all?" Boost.Regex is designed so that multiple threads can share the same immutable regex object. 2) Regex matching: the library needs a stack for the FSM to work on. On Unix like systems this memory is cached and obtained from the routines near the end of regex.cpp, you could replace these with thread specific allocators if this is the overhead. Or.... you could define BOOST_REGEX_RECURSIVE and rebuild everything: regex will then use a program-stack-recursive algorithm that saves on memory allocations, but runs the risk of stack overflow. If you are on a platform that can protect you from stack overruns then this can speed things up a little for single threaded apps, and maybe rather more for multithreaded ones. 3) The final match_results allocation: only once per match/search operation does match_results actually allocate any memory - right at the end when the object is written to with the results. You can avoid even that, if you reuse match_results objects so that they already contain a large enough buffer when they're actually used. HTH, John.