Ok, done.
Thanks
On Wed, Nov 30, 2016 at 2:02 PM, Kinkie wrote:
> I'll do that tonight, but after the rever of std::regex which it clashes with.
>
> On Wed, Nov 30, 2016 at 12:31 PM, Amos Jeffries wrote:
>> On 15/11/2016 5:34 a.m., Kinkie wrote:
>>> Hi,
>>> the attached patch fixes the issue w
I'll do that tonight, but after the rever of std::regex which it clashes with.
On Wed, Nov 30, 2016 at 12:31 PM, Amos Jeffries wrote:
> On 15/11/2016 5:34 a.m., Kinkie wrote:
>> Hi,
>> the attached patch fixes the issue with missing ACL entries
>> (verified) and streamlines the code a bit.
>>
>
On 15/11/2016 5:34 a.m., Kinkie wrote:
> Hi,
> the attached patch fixes the issue with missing ACL entries
> (verified) and streamlines the code a bit.
>
> Performance-wise it improves a bit, parsing the same 1M-entry ACL in
> 19.4 seconds (17.8 seconds in userland).
>
+1. Seems to be okay.
I
> For the record, I do not plan on reviewing this patch further. I did
> what I could, but there is just too much information missing for me to
> reconstruct the exact intent and evaluate the results. IMHO, I should
> not be parsing large raw dumps to figure out what the patch does or does
> not do
On 11/13/2016 11:02 PM, Amos Jeffries wrote:
> 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
>>>
Hi,
the attached patch fixes the issue with missing ACL entries
(verified) and streamlines the code a bit.
Performance-wise it improves a bit, parsing the same 1M-entry ACL in
19.4 seconds (17.8 seconds in userland).
On Mon, Nov 14, 2016 at 11:04 AM, Kinkie wrote:
> On Mon, Nov 14, 2016 at 5
>> The code managing case-insensitivity flags is IMO quite complicated
>> and not really intuitive: it switches between case-insensitive and
>> case-sensitive each time it meets a -i flag.
>
> It does?! Wow! The documentation says that +i switches back to
> case-sensitive rather than repeating -i v
On Mon, Nov 14, 2016 at 5:59 AM, Amos Jeffries wrote:
> 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 a
On Mon, Nov 14, 2016 at 5:36 AM, 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 rege
On Mon, Nov 14, 2016 at 5:30 AM, 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
>> mg
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 int
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
>> mgr:confi
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 slight
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 code
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 all
16 matches
Mail list logo
