On 24 Nov 2015, at 6:36 PM, Yann Ylavic wrote:
> Sure, but my point is that the worst case is likely depend on the
> application,
It will depend on the application, yes.
> eg:
>
>case 'm':
>case 'M':
>if (!strncmp(token, "max-age", 7)
>|| !ap_casecmpstrn(token, "max-age", 7
On Tue, Nov 24, 2015 at 7:29 PM, William A Rowe Jr wrote:
>
> I'm wondering the other way around. Even in Yann's latest exercise,
> simply testing
>
>if ((*ps1 == *ps2) || (ucharmap[*ps1] != ucharmap[*ps2])) {
>
> (or in Yann's code, use the const int lookups, considering that they
> should b
> On Nov 24, 2015, at 1:11 PM, Yann Ylavic wrote:
>
> On Tue, Nov 24, 2015 at 7:03 PM, Jim Jagielski wrote:
>>
>>> On Nov 24, 2015, at 11:18 AM, Graham Leggett wrote:
>>>
>>> On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
>>>
Not sure:
if (!strcmp(h, "max-age")
|| ap_c
On Tue, Nov 24, 2015 at 12:03 PM, Jim Jagielski wrote:
>
> > On Nov 24, 2015, at 11:18 AM, Graham Leggett wrote:
> >
> > On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
> >
> >> Not sure:
> >> if (!strcmp(h, "max-age")
> >> || ap_cmpcasestr(h, "max-age"))
> >> is likely to be a bit faste
On Tue, Nov 24, 2015 at 7:03 PM, Jim Jagielski wrote:
>
>> On Nov 24, 2015, at 11:18 AM, Graham Leggett wrote:
>>
>> On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
>>
>>> Not sure:
>>> if (!strcmp(h, "max-age")
>>> || ap_cmpcasestr(h, "max-age"))
>>> is likely to be a bit faster than a s
+1 (concept)
> On Nov 24, 2015, at 12:40 PM, William A Rowe Jr wrote:
>
> On Tue, Nov 24, 2015 at 10:18 AM, Graham Leggett wrote:
> On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
>
> > Not sure:
> >if (!strcmp(h, "max-age")
> >|| ap_cmpcasestr(h, "max-age"))
> > is likely to be a
> On Nov 24, 2015, at 11:18 AM, Graham Leggett wrote:
>
> On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
>
>> Not sure:
>> if (!strcmp(h, "max-age")
>> || ap_cmpcasestr(h, "max-age"))
>> is likely to be a bit faster than a single ap_cmpcasestr() when it
>> matches, but much slower when
On Tue, Nov 24, 2015 at 10:18 AM, Graham Leggett wrote:
> On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
>
> > Not sure:
> >if (!strcmp(h, "max-age")
> >|| ap_cmpcasestr(h, "max-age"))
> > is likely to be a bit faster than a single ap_cmpcasestr() when it
> > matches, but much slower
On Tue, Nov 24, 2015 at 5:18 PM, Graham Leggett wrote:
> On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
>
>> Not sure:
>>if (!strcmp(h, "max-age")
>>|| ap_cmpcasestr(h, "max-age"))
>> is likely to be a bit faster than a single ap_cmpcasestr() when it
>> matches, but much slower when i
On 24 Nov 2015, at 6:15 PM, Yann Ylavic wrote:
> Not sure:
>if (!strcmp(h, "max-age")
>|| ap_cmpcasestr(h, "max-age"))
> is likely to be a bit faster than a single ap_cmpcasestr() when it
> matches, but much slower when it does not.
Yep, that’s the point.
The vast majority of compar
On Tue, Nov 24, 2015 at 5:09 PM, Graham Leggett wrote:
>
> A further optimisation - in many cases the fast path is really a case
> sensitive string comparison, given that the vast majority of the time the
> case being used is the case quoted in the spec.
>
> In other words, while mAx-AgE is vali
On 24 Nov 2015, at 5:21 PM, Jim Jagielski wrote:
> For these types of paths, where we use a switch/case against
> the 1st char of the token, the real reason why we used that
> impl was to avoid the (expected) expensive string comparison.
>
> This is really no longer an issue. Sure, we could stil
On Tue, Nov 24, 2015 at 4:49 PM, William A Rowe Jr wrote:
>
> Does it make sense to expose the ap_tolower_ascii() function?
+1, possibly an inline one or a macro...
> We could call it ap_tolower_plaintext()
I prefer ascii().
On Tue, Nov 24, 2015 at 9:28 AM, Eric Covener wrote:
> On Tue, Nov 24, 2015 at 10:21 AM, Jim Jagielski wrote:
> > For these types of paths, where we use a switch/case against
> > the 1st char of the token, the real reason why we used that
> > impl was to avoid the (expected) expensive string com
> On Nov 24, 2015, at 10:28 AM, Eric Covener wrote:
>
> On Tue, Nov 24, 2015 at 10:21 AM, Jim Jagielski wrote:
>> For these types of paths, where we use a switch/case against
>> the 1st char of the token, the real reason why we used that
>> impl was to avoid the (expected) expensive string comp
On Tue, Nov 24, 2015 at 4:28 PM, Eric Covener wrote:
> On Tue, Nov 24, 2015 at 10:21 AM, Jim Jagielski wrote:
>> For these types of paths, where we use a switch/case against
>> the 1st char of the token, the real reason why we used that
>> impl was to avoid the (expected) expensive string compari
On Tue, Nov 24, 2015 at 10:21 AM, Jim Jagielski wrote:
> For these types of paths, where we use a switch/case against
> the 1st char of the token, the real reason why we used that
> impl was to avoid the (expected) expensive string comparison.
Maybe naively, I thought we were saving some potentia
For these types of paths, where we use a switch/case against
the 1st char of the token, the real reason why we used that
impl was to avoid the (expected) expensive string comparison.
This is really no longer an issue. Sure, we could still use
this "fast path" short-circuit, but even that is non-op
18 matches
Mail list logo
