On 24 Nov 2015, at 5:21 PM, Jim Jagielski <j...@jagunet.com> 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 still use
> this "fast path" short-circuit, but even that is non-optimal.
> For the below, what we really should be testing is:
>
> if (!ap_casecmpstr(token+1, "ublic")) {
>
> for example.
>
> Sooooo the question is: Do we remove these silly fast-paths
> that no longer make sense[1] or optimize for the "we know the
> 1st char" case ala the above?
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 valid, it is almost always max-age.
Does it make sense to do a case sensitive comparison first, and then fall back
to case insensitive?
Regards,
Graham
—
