diff options
| author | Bruce Hill <bruce@bruce-hill.com> | 2021-01-18 12:53:44 -0800 |
|---|---|---|
| committer | Bruce Hill <bruce@bruce-hill.com> | 2021-01-18 12:53:44 -0800 |
| commit | e82fcefac8af1605c2e930980572c232f4a92e6c (patch) | |
| tree | 530b98ce1efa6e49e47d67cc0c9d890386e0ac1c /README.md | |
| parent | 71471476be004f65abb75cd3817046dcf433d203 (diff) | |
Added perf notes
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 17 |
1 files changed, 17 insertions, 0 deletions
@@ -130,6 +130,23 @@ Testing for these grammar files (other than `builtins`) is iffy at this point, so use at your own risk! These grammar files are only approximations of syntax. +## Performance + +Currently, `bp` is super slow compared to hyper-optimized regex tools like +`grep` and `ripgrep`. `bp` is **not** matching regular expressions, so this is +not strictly a fair comparison. By definition, regular expressions can be +implemented using finite state machines, which are very efficient. Most regex +tools also add the additional restriction that matches must be within a single +line. `bp` on the other hand, uses parsing expression grammars, which can match +arbitrarily complicated or nested structures, requiring a dynamic call stack +and potentially unbounded memory use. This makes `bp` patterns much more +expressive, but harder to optimize. At this point in time, `bp`'s +implementation also uses a fairly naive virtual machine written in C, which is +not very heavily optimized. As a result, `bp` runs quite fast over thousands of +lines of code, reasonably fast over tens of thousands of lines of code, and +pretty slow over millions of lines of code. + + ## License BP is provided under the MIT license with the [Commons Clause](https://commonsclause.com/) |
