Re: [Boost-users] Boost regex multi-processor scalability anduser-defined allocators

From: John Maddock (john_at_[hidden])
Date: 2006-08-22 06:51:44

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.