RequestFactory: optimized script path detection performance#35
RequestFactory: optimized script path detection performance#35JanTvrdik wants to merge 2 commits intonette:masterfrom
Conversation
e241565 to
8851c4d
Compare
src/Http/RequestFactory.php
Outdated
There was a problem hiding this comment.
j should be defined outside. ;)
There was a problem hiding this comment.
Why? This a common pattern. Is that confusing? Or is there a bug I don't see?
There was a problem hiding this comment.
it's common pattern if it's used only in scope of cycle. your code use it outside, there is no bug, it's just less readable.
There was a problem hiding this comment.
This works in PHP, because it has crappy scope boundaries. But would not work e.g. in C++ (unless -fpermissive is set). +1 for moving it outside.
There was a problem hiding this comment.
I think it's readable enough. And I would not say that PHP has crappy scope boundaries – they just follow different rules than C/C++ (and other languages, of course) and I took advantage of those rules. So I'm keeping it unless @dg says otherwise.
|
You should use sentinel (i.e. $script .= '/';
$path = $url->getPath() . '/';
$max = min(strlen($path), strlen($script));
for ($i = 0, $j = 0; $i < $max; $i++) {
if ($path[$i] !== $script[$i] && strcasecmp($path[$i], $script[$i])) {
break;
} elseif ($path[$i] === '/') {
$j = $i;
}
}Test it with: |
8851c4d to
1c1ff1f
Compare
|
Good job with finding the failing use-case, I added it to the tests. The trailing slash was something I intentionally wanted to avoid. |
fa5188e to
e8350c4
Compare
|
One thing I don't understand is why we bother with case-insensitive comparison at all. Shouldn't URL path be generally considered case-sensitive? Also – we don't have unit tests for that. We should either add them or remove the case-insensitive behavior altogether. Just to make it clear – this is no longer about performance, the optimized script path detection algorithm has close to zero slowdown due to the case-insensitivity. This is about what is technically right and wrong. |
|
One more thing – the case sensitivity was introduced in nette/nette@838abc3. However I'm unable to find a failing use-case for the previous implementation. Both known script path issues (http://forum.nette.org/cs/5932-lepsi-detekce-requesturi-a-scriptpath and nette/nette#489) worked on the ancient version properly. |
|
It was introduced sooner, in 2008. But I have no idea why… I think it can be removed. |
|
My guess is that the intention was to be compatible with Win-world. How does your webserver on Win handle URLs like http://localhost/DIR/INDEX.HTML or http://localhost/dir/index.html without URL rewriting? |
|
Mac world is case insensitive too. |
|
@xificurk But |
|
@JanTvrdik You're right, this should be solved somewhere else... I was just guessing (not sure if correctly), what was the reason to introduce it in the first place. |
e8350c4 to
98cc19a
Compare
98cc19a to
c5aa73e
Compare
|
I've found on forum and added the missing failing case for the ancient script path detection algorithms. I've also found what does removing the case-insensitivity break: On Windows (and possibly other platforms with case-insensitive file system) if you access Therefore it still works fine even with case-sensitive behavior. However if for some reasons the |
Micro-optimization.
Benchmark:
Results: