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.
