{"thread":{"id":"47034","subject":"grep vs git grep performance?","startedAt":"2017-10-26T15:08:21Z","lastAt":"2017-10-28T07:46:05Z","messageCount":12,"participants":["Joe Perches","Han-Wen Nienhuys","SZEDER Gábor","Stefan Beller","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"331087","messageId":"1509030170.10651.59.camel@perches.com","threadId":"47034","inReplyTo":null,"subject":"grep vs git grep performance?","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2017-10-26T15:02:50Z","receivedAt":"2017-10-26T15:08:21Z","isPatch":false,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"Comparing a cache warm git grep vs command line grep\nshows significant differences in cpu & wall clock.\n\nAny ideas how to improve this?\n\n$ time git grep \"\\bseq_.*%p\\W\" | wc -l\n112\n\nreal\t0m4.271s\nuser\t0m15.520s\nsys\t0m0.395s\n\n$ time grep -r --include=*.[ch] \"\\bseq_.*%p\\W\" * | wc -l\n112\n\nreal\t0m1.164s\nuser\t0m0.847s\nsys\t0m0.314s\n\n\n"},{"id":"331088","messageId":"CAFQ2z_P9bpw+Pc2DhJTCB8dxj-5JAKLE=nyvToGuiRA8wV66Wg@mail.gmail.com","threadId":"47034","inReplyTo":"1509030170.10651.59.camel@perches.com","subject":"Re: grep vs git grep performance?","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@google.com","sentAt":"2017-10-26T15:11:07Z","receivedAt":"2017-10-26T15:11:32Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"On Thu, Oct 26, 2017 at 5:02 PM, Joe Perches <joe@perches.com> wrote:\n> Comparing a cache warm git grep vs command line grep\n> shows significant differences in cpu & wall clock.\n>\n> Any ideas how to improve this?\n\nIs git-grep multithreaded? IIRC, grep -r uses multiple threads. (Do\nyou have a 4-core machine?)\n\n--\n\nGoogle Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich\n\nRegistergericht und -nummer: Hamburg, HRB 86891\n\nSitz der Gesellschaft: Hamburg\n\nGeschäftsführer: Paul Manicle, Halimah DeLaine Prado\n"},{"id":"331091","messageId":"1509033321.11245.3.camel@perches.com","threadId":"47034","inReplyTo":"CAFQ2z_P9bpw+Pc2DhJTCB8dxj-5JAKLE=nyvToGuiRA8wV66Wg@mail.gmail.com","subject":"Re: grep vs git grep performance?","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2017-10-26T15:55:21Z","receivedAt":"2017-10-26T15:55:38Z","isPatch":false,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Thu, 2017-10-26 at 17:11 +0200, Han-Wen Nienhuys wrote:\n> On Thu, Oct 26, 2017 at 5:02 PM, Joe Perches <joe@perches.com> wrote:\n> > Comparing a cache warm git grep vs command line grep\n> > shows significant differences in cpu & wall clock.\n> > \n> > Any ideas how to improve this?\n> \n> Is git-grep multithreaded?\n\nYes, at least according to the documentation\n\n$ git grep --help\n[]\n       grep.threads\n           Number of grep worker threads to use. If unset (or set to 0), 8\n           threads are used by default (for now).\n\n> IIRC, grep -r uses multiple threads. (Do\n> you have a 4-core machine?)\n\nI have a 2 core machine with hyperthreading\n\n$ cat /proc/cpuinfo\n[]\nmodel name\t: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz\nstepping\t: 3\nmicrocode\t: 0xba\ncpu MHz\t\t: 2400.000\ncache size\t: 3072 KB\nphysical id\t: 0\nsiblings\t: 4\ncore id\t\t: 0\ncpu cores\t: 2\n\n"},{"id":"331092","messageId":"20171026161354.23037-1-szeder.dev@gmail.com","threadId":"47034","inReplyTo":"1509030170.10651.59.camel@perches.com","subject":"Re: grep vs git grep performance?","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-10-26T16:13:54Z","receivedAt":"2017-10-26T16:14:14Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"> Comparing a cache warm git grep vs command line grep\n> shows significant differences in cpu & wall clock.\n> \n> Any ideas how to improve this?\n> \n> $ time git grep \"\\bseq_.*%p\\W\" | wc -l\n> 112\n> \n> real\t0m4.271s\n> user\t0m15.520s\n> sys\t0m0.395s\n> \n> $ time grep -r --include=*.[ch] \"\\bseq_.*%p\\W\" * | wc -l\n> 112\n> \n> real\t0m1.164s\n> user\t0m0.847s\n> sys\t0m0.314s\n\nNote that this \"regular\" grep is limited to *.c and *.h files, while\nthe above git grep invocation isn't and has to look at all tracked\nfiles.  How does\n\n  git grep \"\\bseq_.*%p\\W\" \"*.[ch]\"\n\nfare?\n\n"},{"id":"331093","messageId":"1509034857.11245.4.camel@perches.com","threadId":"47034","inReplyTo":"20171026161354.23037-1-szeder.dev@gmail.com","subject":"Re: grep vs git grep performance?","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2017-10-26T16:20:57Z","receivedAt":"2017-10-26T16:21:06Z","isPatch":false,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Thu, 2017-10-26 at 18:13 +0200, SZEDER Gábor wrote:\n> > Comparing a cache warm git grep vs command line grep\n> > shows significant differences in cpu & wall clock.\n> > \n> > Any ideas how to improve this?\n> > \n> > $ time git grep \"\\bseq_.*%p\\W\" | wc -l\n> > 112\n> > \n> > real\t0m4.271s\n> > user\t0m15.520s\n> > sys\t0m0.395s\n> > \n> > $ time grep -r --include=*.[ch] \"\\bseq_.*%p\\W\" * | wc -l\n> > 112\n> > \n> > real\t0m1.164s\n> > user\t0m0.847s\n> > sys\t0m0.314s\n> \n> Note that this \"regular\" grep is limited to *.c and *.h files, while\n> the above git grep invocation isn't and has to look at all tracked\n> files.  How does\n> \n>   git grep \"\\bseq_.*%p\\W\" \"*.[ch]\"\n> \n> fare?\n\nSame-ish\n\n$ time git grep \"\\bseq_.*%p\\W\" -- \"*.[ch]\" | wc -l\n112\n\nreal\t0m4.225s\nuser\t0m14.485s\nsys\t0m0.413s\n"},{"id":"331095","messageId":"CAGZ79ka41NdzNxGAvtVW802088KydKkp3yHx=Z5q3Mc9GGa_+g@mail.gmail.com","threadId":"47034","inReplyTo":"1509030170.10651.59.camel@perches.com","subject":"Re: grep vs git grep performance?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-10-26T16:58:51Z","receivedAt":"2017-10-26T16:59:06Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"+ Avar who knows a thing about pcre (I assume the regex compilation\nhas impact on grep speed)\n\nOn Thu, Oct 26, 2017 at 8:02 AM, Joe Perches <joe@perches.com> wrote:\n> Comparing a cache warm git grep vs command line grep\n> shows significant differences in cpu & wall clock.\n>\n> Any ideas how to improve this?\n>\n> $ time git grep \"\\bseq_.*%p\\W\" | wc -l\n> 112\n>\n> real    0m4.271s\n> user    0m15.520s\n> sys     0m0.395s\n>\n> $ time grep -r --include=*.[ch] \"\\bseq_.*%p\\W\" * | wc -l\n> 112\n>\n> real    0m1.164s\n> user    0m0.847s\n> sys     0m0.314s\n>\n\nI wonder how much is algorithmic advantage vs coding/micro\noptimization that we can do.\n"},{"id":"331099","messageId":"1509039696.11245.9.camel@perches.com","threadId":"47034","inReplyTo":"CAGZ79ka41NdzNxGAvtVW802088KydKkp3yHx=Z5q3Mc9GGa_+g@mail.gmail.com","subject":"Re: grep vs git grep performance?","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2017-10-26T17:41:36Z","receivedAt":"2017-10-26T17:41:46Z","isPatch":false,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:\n> + Avar who knows a thing about pcre (I assume the regex compilation\n> has impact on grep speed)\n> \n> On Thu, Oct 26, 2017 at 8:02 AM, Joe Perches <joe@perches.com> wrote:\n> > Comparing a cache warm git grep vs command line grep\n> > shows significant differences in cpu & wall clock.\n> > \n> > Any ideas how to improve this?\n> > \n> > $ time git grep \"\\bseq_.*%p\\W\" | wc -l\n> > 112\n> > \n> > real    0m4.271s\n> > user    0m15.520s\n> > sys     0m0.395s\n> > \n> > $ time grep -r --include=*.[ch] \"\\bseq_.*%p\\W\" * | wc -l\n> > 112\n> > \n> > real    0m1.164s\n> > user    0m0.847s\n> > sys     0m0.314s\n> > \n> \n> I wonder how much is algorithmic advantage vs coding/micro\n> optimization that we can do.\n\nAs do I.  I presume this is libpcre related.\n\nFor instance, git grep performance is better than grep for:\n\n$ time git grep -w \"seq_printf\" -- \"*.[ch]\" | wc -l\n8609\n\nreal\t0m0.301s\nuser\t0m0.548s\nsys\t0m0.372s\n\n$ time grep -w -r --include=*.[ch] \"seq_printf\" * | wc -l\n8609\n\nreal\t0m0.706s\nuser\t0m0.396s\nsys\t0m0.309s\n\n\n"},{"id":"331101","messageId":"CAGZ79kYWPunzZ2u=MtCoCadxXu_4etEK5DYnhYXo+CgeHrXQwQ@mail.gmail.com","threadId":"47034","inReplyTo":"1509039696.11245.9.camel@perches.com","subject":"Re: grep vs git grep performance?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2017-10-26T17:45:57Z","receivedAt":"2017-10-26T17:46:03Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Thu, Oct 26, 2017 at 10:41 AM, Joe Perches <joe@perches.com> wrote:\n> On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:\n>> + Avar who knows a thing about pcre (I assume the regex compilation\n>> has impact on grep speed)\n>>\n>> On Thu, Oct 26, 2017 at 8:02 AM, Joe Perches <joe@perches.com> wrote:\n>> > Comparing a cache warm git grep vs command line grep\n>> > shows significant differences in cpu & wall clock.\n>> >\n>> > Any ideas how to improve this?\n>> >\n>> > $ time git grep \"\\bseq_.*%p\\W\" | wc -l\n>> > 112\n>> >\n>> > real    0m4.271s\n>> > user    0m15.520s\n>> > sys     0m0.395s\n>> >\n>> > $ time grep -r --include=*.[ch] \"\\bseq_.*%p\\W\" * | wc -l\n>> > 112\n>> >\n>> > real    0m1.164s\n>> > user    0m0.847s\n>> > sys     0m0.314s\n>> >\n>>\n>> I wonder how much is algorithmic advantage vs coding/micro\n>> optimization that we can do.\n>\n> As do I.  I presume this is libpcre related.\n>\n> For instance, git grep performance is better than grep for:\n>\n> $ time git grep -w \"seq_printf\" -- \"*.[ch]\" | wc -l\n> 8609\n>\n> real    0m0.301s\n> user    0m0.548s\n> sys     0m0.372s\n>\n> $ time grep -w -r --include=*.[ch] \"seq_printf\" * | wc -l\n> 8609\n>\n> real    0m0.706s\n> user    0m0.396s\n> sys     0m0.309s\n>\n\nOne important piece of information is what version of Git you are running,\n\n\n$ git tag --contains origin/ab/pcre-v2\nv2.14.0\n...\n\n(and the version of pcre, see the numbers)\nhttps://git.kernel.org/pub/scm/git/git.git/commit/?id=94da9193a6eb8f1085d611c04ff8bbb4f5ae1e0a\n"},{"id":"331179","messageId":"1509124942.1914.9.camel@perches.com","threadId":"47034","inReplyTo":"CAGZ79kYWPunzZ2u=MtCoCadxXu_4etEK5DYnhYXo+CgeHrXQwQ@mail.gmail.com","subject":"Re: grep vs git grep performance?","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2017-10-27T17:22:22Z","receivedAt":"2017-10-27T17:22:32Z","isPatch":false,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Thu, 2017-10-26 at 10:45 -0700, Stefan Beller wrote:\n> On Thu, Oct 26, 2017 at 10:41 AM, Joe Perches <joe@perches.com> wrote:\n> > On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:\n> > > + Avar who knows a thing about pcre (I assume the regex compilation\n> > > has impact on grep speed)\n> > > \n> > > On Thu, Oct 26, 2017 at 8:02 AM, Joe Perches <joe@perches.com> wrote:\n> > > > Comparing a cache warm git grep vs command line grep\n> > > > shows significant differences in cpu & wall clock.\n> > > > \n> > > > Any ideas how to improve this?\n> > > > \n> > > > $ time git grep \"\\bseq_.*%p\\W\" | wc -l\n> > > > 112\n> > > > \n> > > > real    0m4.271s\n> > > > user    0m15.520s\n> > > > sys     0m0.395s\n> > > > \n> > > > $ time grep -r --include=*.[ch] \"\\bseq_.*%p\\W\" * | wc -l\n> > > > 112\n> > > > \n> > > > real    0m1.164s\n> > > > user    0m0.847s\n> > > > sys     0m0.314s\n> > > > \n> > > \n> > > I wonder how much is algorithmic advantage vs coding/micro\n> > > optimization that we can do.\n> > \n> > As do I.  I presume this is libpcre related.\n> > \n> > For instance, git grep performance is better than grep for:\n> > \n> > $ time git grep -w \"seq_printf\" -- \"*.[ch]\" | wc -l\n> > 8609\n> > \n> > real    0m0.301s\n> > user    0m0.548s\n> > sys     0m0.372s\n> > \n> > $ time grep -w -r --include=*.[ch] \"seq_printf\" * | wc -l\n> > 8609\n> > \n> > real    0m0.706s\n> > user    0m0.396s\n> > sys     0m0.309s\n> > \n> \n> One important piece of information is what version of Git you are running,\n> \n> \n> $ git tag --contains origin/ab/pcre-v2\n> v2.14.0\n\nv2.10\n\n> ...\n> \n> (and the version of pcre, see the numbers)\n> https://git.kernel.org/pub/scm/git/git.git/commit/?id=94da9193a6eb8f1085d611c04ff8bbb4f5ae1e0a\n\nI definitely didn't have that one.\n\nI recompiled git latest (with USE_LIBPCRE2) and reran.\n\nHere are the results\n\n$ git --version\ngit version 2.15.0.rc2.48.g4e40fb3\n\n$ time git grep -P \"\\bseq_.*%p\\W\" -- \"*.[ch]\" | wc -l\n112\n\nreal\t0m0.437s\nuser\t0m1.008s\nsys\t0m0.381s\n\nSo, git grep performance has already been\nquite successfully improved.\n\nThanks.\n\n"},{"id":"331187","messageId":"877evgxmu7.fsf@evledraar.booking.com","threadId":"47034","inReplyTo":"1509124942.1914.9.camel@perches.com","subject":"Re: grep vs git grep performance?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-10-27T22:11:44Z","receivedAt":"2017-10-27T22:11:53Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Oct 27 2017, Joe Perches jotted:\n\n> On Thu, 2017-10-26 at 10:45 -0700, Stefan Beller wrote:\n>> On Thu, Oct 26, 2017 at 10:41 AM, Joe Perches <joe@perches.com> wrote:\n>> > On Thu, 2017-10-26 at 09:58 -0700, Stefan Beller wrote:\n>> > > + Avar who knows a thing about pcre (I assume the regex compilation\n>> > > has impact on grep speed)\n>> > >\n>> > > On Thu, Oct 26, 2017 at 8:02 AM, Joe Perches <joe@perches.com> wrote:\n>> > > > Comparing a cache warm git grep vs command line grep\n>> > > > shows significant differences in cpu & wall clock.\n>> > > >\n>> > > > Any ideas how to improve this?\n>> > > >\n>> > > > $ time git grep \"\\bseq_.*%p\\W\" | wc -l\n>> > > > 112\n>> > > >\n>> > > > real    0m4.271s\n>> > > > user    0m15.520s\n>> > > > sys     0m0.395s\n>> > > >\n>> > > > $ time grep -r --include=*.[ch] \"\\bseq_.*%p\\W\" * | wc -l\n>> > > > 112\n>> > > >\n>> > > > real    0m1.164s\n>> > > > user    0m0.847s\n>> > > > sys     0m0.314s\n>> > > >\n>> > >\n>> > > I wonder how much is algorithmic advantage vs coding/micro\n>> > > optimization that we can do.\n>> >\n>> > As do I.  I presume this is libpcre related.\n>> >\n>> > For instance, git grep performance is better than grep for:\n>> >\n>> > $ time git grep -w \"seq_printf\" -- \"*.[ch]\" | wc -l\n>> > 8609\n>> >\n>> > real    0m0.301s\n>> > user    0m0.548s\n>> > sys     0m0.372s\n>> >\n>> > $ time grep -w -r --include=*.[ch] \"seq_printf\" * | wc -l\n>> > 8609\n>> >\n>> > real    0m0.706s\n>> > user    0m0.396s\n>> > sys     0m0.309s\n>> >\n>>\n>> One important piece of information is what version of Git you are running,\n>>\n>>\n>> $ git tag --contains origin/ab/pcre-v2\n>> v2.14.0\n>\n> v2.10\n>\n>> ...\n>>\n>> (and the version of pcre, see the numbers)\n>> https://git.kernel.org/pub/scm/git/git.git/commit/?id=94da9193a6eb8f1085d611c04ff8bbb4f5ae1e0a\n>\n> I definitely didn't have that one.\n>\n> I recompiled git latest (with USE_LIBPCRE2) and reran.\n>\n> Here are the results\n>\n> $ git --version\n> git version 2.15.0.rc2.48.g4e40fb3\n>\n> $ time git grep -P \"\\bseq_.*%p\\W\" -- \"*.[ch]\" | wc -l\n> 112\n>\n> real\t0m0.437s\n> user\t0m1.008s\n> sys\t0m0.381s\n>\n> So, git grep performance has already been\n> quite successfully improved.\n\n...and I have WIP patches to use the PCRE engine for patterns without -P\nwhich I intend to start sending soon after the next release.\n"},{"id":"331193","messageId":"1509146542.1914.19.camel@perches.com","threadId":"47034","inReplyTo":"877evgxmu7.fsf@evledraar.booking.com","subject":"Re: grep vs git grep performance?","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2017-10-27T23:22:22Z","receivedAt":"2017-10-27T23:22:32Z","isPatch":false,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Sat, 2017-10-28 at 00:11 +0200, Ævar Arnfjörð Bjarmason wrote:\n> On Fri, Oct 27 2017, Joe Perches jotted:\n[]\n> > git grep performance has already been\n> > quite successfully improved.\n> \n> ...and I have WIP patches to use the PCRE engine for patterns without -P\n> which I intend to start sending soon after the next release.\n\nOne addition that would be quite nice would be\nan option to have regex matches span input lines.\n\ngrep v2.54 was the last grep version that allowed\nthis and I keep it around just for that.\n\nie:\n\n$ cat hello.txt \nHello\nWorld\n$ grep -P \"Hello\\s*World\" hello.txt \n$ grep-2.5.4 -P \"Hello\\s*World\" hello.txt \nHello\nWorld\n\n"},{"id":"331205","messageId":"8760azyato.fsf@evledraar.booking.com","threadId":"47034","inReplyTo":"1509146542.1914.19.camel@perches.com","subject":"Re: grep vs git grep performance?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-10-28T07:45:55Z","receivedAt":"2017-10-28T07:46:05Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, Oct 27 2017, Joe Perches jotted:\n\n> On Sat, 2017-10-28 at 00:11 +0200, Ævar Arnfjörð Bjarmason wrote:\n>> On Fri, Oct 27 2017, Joe Perches jotted:\n> []\n>> > git grep performance has already been\n>> > quite successfully improved.\n>>\n>> ...and I have WIP patches to use the PCRE engine for patterns without -P\n>> which I intend to start sending soon after the next release.\n>\n> One addition that would be quite nice would be\n> an option to have regex matches span input lines.\n>\n> grep v2.54 was the last grep version that allowed\n> this and I keep it around just for that.\n>\n> ie:\n>\n> $ cat hello.txt\n> Hello\n> World\n> $ grep -P \"Hello\\s*World\" hello.txt\n> $ grep-2.5.4 -P \"Hello\\s*World\" hello.txt\n> Hello\n> World\n\nI'm unable to build 2.5.4 and can't find anything relevant in the\nrelease notes at a quick glance around that time saying that this would\nbe removed, if you can still build it I'd be interested to see what this\nbisects down to in grep.git.\n\nBut aside from that, a feature like this constrains the regex\nimplementation a lot since it's going to need to either match the entire\nfile as we'd need to do with PCRE, or we'd need to really deeply embed\nthe core logic of the regex matcher into our grep implementation.\n\nI.e. in this case a more optimal implementation would start by parsing\nthis regex down:\n\n    ((EXACT \"Hello\")\n     (STAR (POSIXU \"\\s\"))\n     (EXACT \"World\"))\n\nThen when you open the file you can start searching for the fixed-string\n\"Hello\", if you don't find that you're done, if you do you can forward\nlook-ahead for the fixed \"World\", and only if you find that do you need\nto match the more complex part in the middle.\n\nWhereas our API for the internal regex matchers now is that we find the\nboundaries of newlines and batch-match a bunch of lines with a match()\nfunction that takes a string, and if that matches we drill down to what\nspecific line matches.\n\nWhich is not to say that this can't be done without a potentially\nunacceptable memory trade-off (i.e. matching the entire file in all\ncases), the PCRE2 engine in particular includes some I/O abstractions\nthat we're not using but could (but I haven't looked into it).\n\nBut right now the entire internal API we have is constrained by catering\nto the lowest common denominator (a regexec that takes a char*), so\nsupporting more fancy multi-line matching features can be a PITA since\nwe'd need to maintain both codepaths.\n\nOr we could make PCRE a hard dependency, which given the performance\nadvantages I'm increasingly willing to make the case for.\n"}]}