On 14/11/2016 6:36 p.m., Alex Rousskov wrote:
> On 11/13/2016 10:15 PM, Amos Jeffries wrote:
>
>> I think we should accumulate into two SBufList instead, one for -i and
>> one for +i instead of switching back and forth with potentially lots of
>> little patterns.
>
> Would not forcing regexes
On 14/11/2016 6:30 p.m., Alex Rousskov wrote:
> On 11/13/2016 05:11 PM, Kinkie wrote:
>
>> the attached patch moves away from hand-rolling a c-string onto
>> joining a SBufList for optimizing regexes in RegexData.cc.
>
>> You can find attached as a test case the output of squidclient
>>
On 11/13/2016 10:15 PM, Amos Jeffries wrote:
> I think we should accumulate into two SBufList instead, one for -i and
> one for +i instead of switching back and forth with potentially lots of
> little patterns.
Would not forcing regexes into two different groups change the regex
evaluation order
On 11/13/2016 05:11 PM, Kinkie wrote:
> the attached patch moves away from hand-rolling a c-string onto
> joining a SBufList for optimizing regexes in RegexData.cc.
> You can find attached as a test case the output of squidclient
> mgr:config taken on trunk and on the submitted code. It is
On 14/11/2016 1:11 p.m., Kinkie wrote:
> Hi all,
> the attached patch moves away from hand-rolling a c-string onto
> joining a SBufList for optimizing regexes in RegexData.cc.
>
> You can find attached as a test case the output of squidclient
> mgr:config taken on trunk and on the submitted
Hi all,
the attached patch moves away from hand-rolling a c-string onto
joining a SBufList for optimizing regexes in RegexData.cc.
You can find attached as a test case the output of squidclient
mgr:config taken on trunk and on the submitted code. It is slightly
different in that the new code