Re: Initial patch for file suffix acl

Lucas Brasilino wrote:
> Hi Amos
>
>> * strrchr() is probably the better for finding the '.'
>> the forward-search is likely to be on average slower than the
>> reverse-search. Particularly for objects without parameters which are
>> in the majority.
>> * strlen(l->key) is relatively quite slow and CPU intensive. If possible
>> it needs to be moved outside the core while-loop. Probably by basing the
>> strncmp length on the tested files ext (or ACL_FILE_SUFFIX_SZ) than on
>> the
>> key.
>> * with the above ACL_FILE_SUFFIX_SZ would be useful then to limit the
>> scanning time as well as the config parsing.
>
> hmmm great idea!
>
>> * ACL_FILE_SUFFIX_SZ should be linked with the appropriate RFC defining
>> the URI part limits instead of an arbitrary 10. I think its likely to be
>> in either RFC2181 or RFC1123.
>
> I have just looked suffixes(7) man page to get an idea of suffix max
> length.

Ok. I just did a quick scan of the RFC and could not see any length
limits. It can wait then.

>
>> * If you want to test for speed, test the difference between a wordlist
>> and a splay tree. The output of strncmp is suitable for the splay test
>> and
>> splay allows a larger scaling over ACL length. Long-term in squid a
>> better
>> tree entirely is probably needed for string comparisons.
>
> I gonna take a look at splay tree implementation. Don't you think a
> hash table is more suitable for this kind of searching?

Depends on the particular code. As I said, if you want, test and see.
You could go as far as writing a new tree that only does a single-pass
search.

Amos

-- 
Please use Squid 2.6STABLE17+ or 3.0STABLE1+
There are serious security advisories out on all earlier releases.