C[omp]ute

From: andrew cooke <andrew@...>

Date: Sat, 17 Jul 2010 16:48:30 -0400

Much of this is just duplicating the re2 work, and the rest is RXPY-specific,
but even so, these are quite interesting (for me, at least).

Note that the times are relative to the Python re package (log10 in brackets).
Also, the plots are both linear ### and logarithmic [ ].


First, some basic matching.  This is just showing how slow my code is
(hundreds of times slower than the re package).

Match a(.)c against abc
             Backtracking [##########                   ]              95 [2.0]
            Parallel wide [#######################            ]       206 [2.3]
    Parallel wide, hashed [#################################### ]     315 [2.5]
             Parallel seq [#######################            ]       205 [2.3]
     Parallel seq, hashed [###################################  ]     304 [2.5]
            Parallel beam [############################        ]      245 [2.4]
    Parallel beam, hashed [######################################]    339 [2.5]

Match (a)b(?<=(?(1)b|x))(c) against abc
             Backtracking [############                   ]           210 [2.3]
            Parallel wide [#########################          ]       398 [2.6]
    Parallel wide, hashed [#################################    ]     531 [2.7]
             Parallel seq [#########################          ]       400 [2.6]
     Parallel seq, hashed [##################################   ]     546 [2.7]
            Parallel beam [##############################      ]      480 [2.7]
    Parallel beam, hashed [######################################]    622 [2.8]

Match a*b against a^100b
             Backtracking [####################################  ]   1902 [3.3]
            Parallel wide [#################################    ]    1737 [3.2]
    Parallel wide, hashed [####################################  ]   1919 [3.3]
             Parallel seq [################################     ]    1733 [3.2]
     Parallel seq, hashed [####################################  ]   1919 [3.3]
            Parallel beam [###################################  ]    1884 [3.3]
    Parallel beam, hashed [######################################]   2073 [3.3]

Match .*b against a^100b
             Backtracking [#################                 ]       1902 [3.3]
            Parallel wide [###############                   ]       1769 [3.2]
    Parallel wide, hashed [#################                 ]       1927 [3.3]
             Parallel seq [###############                   ]       1757 [3.2]
     Parallel seq, hashed [##################                ]       2015 [3.3]
            Parallel beam [###################################  ]    3825 [3.6]
    Parallel beam, hashed [######################################]   4300 [3.6]

Above is quite interesting because the beam search is suddenly twice as slow,
just by changing from "a*b" to ".*b".  That's because the second expression
has a failure ("." matchs the final "b") and so needs to backtrack.  Because
the initial beam width is 1 that means that the entire search must be repeated
with doubled with.


The next test is a search.

Search .*b against a^100b
             Backtracking [                         ]                1172 [3.1]
            Parallel wide [######################################]  41841 [4.6]
    Parallel wide, hashed [                         ]                1459 [3.2]
             Parallel seq [                         ]                1212 [3.1]
     Parallel seq, hashed [                         ]                1338 [3.1]
            Parallel beam [###                          ]            3764 [3.6]
    Parallel beam, hashed [###                          ]            3688 [3.6]

Above shows the problem with a naive wide parallel approach - there are an
awful lot of different states to store.  Of course, most are duplicates so the
hashing removes the problem (as does sequential or beam search).


The next tests show the exponential explosion problem in Python's matcher.
This is a little more difficult to trigger than in the re2 paper because
Python has a "shortcut" (hack!) that avoids the problem in very simple cases
(but, as we will see below, does nothing to address the underlying issues).

Match (?:a|b)?^2n(?:ab)^n against (ab)^n for n=4
             Backtracking [#############                   ]          573 [2.8]
            Parallel wide [#########                     ]            392 [2.6]
    Parallel wide, hashed [##                      ]                  125 [2.1]
             Parallel seq [#########                     ]            398 [2.6]
     Parallel seq, hashed [##                      ]                  125 [2.1]
            Parallel beam [######################################]   1606 [3.2]
    Parallel beam, hashed [########                      ]            360 [2.6]

Match (?:a|b)?^2n(?:ab)^n against (ab)^n for n=6
             Backtracking [######################################]    637 [2.8]
            Parallel wide [#############################       ]      476 [2.7]
    Parallel wide, hashed [#                 ]                         27 [1.4]
             Parallel seq [#############################       ]      475 [2.7]
     Parallel seq, hashed [#                 ]                         27 [1.4]
    Parallel beam, hashed [##                    ]                     51 [1.7]

Match (?:a|b)?^2n(?:ab)^n against (ab)^n for n=8
    Parallel wide, hashed [##############       ]                       4 [0.6]
     Parallel seq, hashed [##############       ]                       4 [0.6]
    Parallel beam, hashed [######################################]     10 [1.0]

As the number of terms increase, only the hashed approaches are efficient (due
to the explosion in the number of states).  This is as expected.  What is nice
to see is that by n=8 my Python code is oly 4x slower than the re package!
This is because the re backtracker is "exploding", while my code is linear
(but slow).


This is only possible, though, when we can discard duplicate state.  Which
isn't so easy when matching groups:

Match (a|b)?^2n(?:ab)^n against (ab)^n for n=4
             Backtracking [#######                       ]            481 [2.7]
            Parallel wide [#####                       ]              378 [2.6]
    Parallel wide, hashed [#########                      ]           627 [2.8]
             Parallel seq [######                       ]             414 [2.6]
     Parallel seq, hashed [##########                     ]           667 [2.8]
            Parallel beam [##########################          ]     1612 [3.2]
    Parallel beam, hashed [######################################]   2415 [3.4]

Match (a|b)?^2n(?:ab)^n against (ab)^n for n=6
             Backtracking [###########################         ]      512 [2.7]
            Parallel wide [######################             ]       415 [2.6]
    Parallel wide, hashed [######################################]    723 [2.9]
             Parallel seq [######################             ]       418 [2.6]
     Parallel seq, hashed [######################################]    714 [2.9]


And here we do no better than normal backtracking.


The main conclusions, then, are:

1 - Python's re package does suffer from the exponential "explosion" issue,
    while my code (with duplicate state elimination) does not.

2 - My code can also handle groups, but the degrades in performance as
    expected.

So RXPY is both general and, when possible, efficient.  Even if it is terribly
slow.

A secondary conclusion is that the beam search approach does not seem to be
worth the trouble.

Andrew