-
-
Notifications
You must be signed in to change notification settings - Fork 9.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A few optimizations #7931
A few optimizations #7931
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,12 +28,13 @@ class ServerBag extends ParameterBag | |
public function getHeaders() | ||
{ | ||
$headers = array(); | ||
$contentHeaders = array('CONTENT_LENGTH' => true, 'CONTENT_MD5' => true, 'CONTENT_TYPE' => true); | ||
foreach ($this->parameters as $key => $value) { | ||
if (0 === strpos($key, 'HTTP_')) { | ||
if ('HTTP_' === substr($key, 0, 5)) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Substr is actually slower, even if the HTTP_ is not present on the string (see below), probably because strpos just iterate on the string, and substr have to allocate new memory, allocating memory is expensive. The only way substr would be faster than strpos is if string is HUGE.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @fabpot Why merge it then? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Because I trust @Seldaek who spent time doing benchmarks on real-world apps. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. IMHO the rest of the PR is ok but this change should be reverted, @Seldaek what do you think ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm ok to revert this bit, but TBH either way doesn't matter so much I There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you like to do a PR to revert that please feel free. I'm busy with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. done in #7943 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @fabpot the simple benchmark was just an example. I don't need a benchmark to tell me that strpos is faster in a lot of cases than substr, I just need to think how I would implement strpos in C (is just a iteration) and i know that is fast, except in case that the string searching is huge. Example of implementation of strstr on C: ftp://ftp.pku.edu.cn/open/UCL/tcl-8.0/compat/strstr.c (strpos can be even faster the second while is not needed if just want to return the position like on strpos). I could spent time doing benchmarks on real-world apps, and I do it but in things that require it, simple things thinking is enough. My comment was not to raise a debate between substr vs strpos, is a micro optimization and I don't care enough about it. I commented because as @pborreli said I noticed that strpos is largely used on Symfony code base. And this pull request is called "A few optimizations" and switch strpos with substr doesn't bring any optimization. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nice @pborreli |
||
$headers[substr($key, 5)] = $value; | ||
} | ||
// CONTENT_* are not prefixed with HTTP_ | ||
elseif (in_array($key, array('CONTENT_LENGTH', 'CONTENT_MD5', 'CONTENT_TYPE'))) { | ||
elseif (isset($contentHeaders[$key])) { | ||
$headers[$key] = $value; | ||
} | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -35,6 +35,7 @@ class RouterListener implements EventSubscriberInterface | |
private $matcher; | ||
private $context; | ||
private $logger; | ||
private $request; | ||
|
||
/** | ||
* Constructor. | ||
|
@@ -72,9 +73,10 @@ public function __construct($matcher, RequestContext $context = null, LoggerInte | |
*/ | ||
public function setRequest(Request $request = null) | ||
{ | ||
if (null !== $request) { | ||
if (null !== $request && $this->request !== $request) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What if some values of the request have changed? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Requests should really not be changed.. And as described in the commit, the problem is that it's always called twice for BC with frameworks that don't call setRequest There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes they should not change. But unfortunately requests are not immutable. So you basically can't make this assumtion. As this its a BC break. |
||
$this->context->fromRequest($request); | ||
} | ||
$this->request = $request; | ||
} | ||
|
||
public function onKernelRequest(GetResponseEvent $event) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think using
{ }
as delimitor is wise when you don't control the regex entered by the user as they have a special meaning in the regex. Can they really be used as delimitor when the regex is\d{3}
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is quite wise yes, especially because the character has a special meaning in regexes. That means it'll already be escaped so no need to escape it. The engine can deal with
\d{3}
just fine since it can count the opening/closing brackets, and skip those that are escaped. That's why I tend to always use{}
as delimiters, because it doesn't add yet another char you have to escape.