-
Notifications
You must be signed in to change notification settings - Fork 356
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
performance improvements #310
Conversation
digitalkaoz
commented
Sep 21, 2016
•
edited
Loading
edited
- fixed unnecessary object references
- avoid unnecessary array_merges
- speedup travis builds
- speedup tests
4f96ab3
to
0a48d3a
Compare
c1cd87c
to
e428b84
Compare
@bighappyface are you willing to review this one? |
3ad7f54
to
0c45504
Compare
return array_key_exists($property, $element) ? $element[$property] : $fallback; | ||
} elseif (is_object($element)) { | ||
return property_exists($element, $property) ? $element->$property : $fallback; | ||
if (is_array($element) && array_key_exists($property, $element) /*$this->checkMode == self::CHECK_MODE_TYPE_CAST*/) { |
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.
what do you think of isset
instead of array_key_exists
which is a lot faster.
this would mean you also need an additional call to array_key_exists
in case it does allow caching of NULL values. In cases were most calls would already be catched by isset($element[property])
this will speedup things a lot.
so the end result would render to something like
if (is_array($element)) {
if (isset($element[property]) || array_key_exists($property, $element)) {
return $element[property];
}
}
// ...
return $fallback;
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.
yeah good point, did it
b67d90e
to
ad93364
Compare
related tweet which shows the measured improvements: |
running it in an isolated environment (a single time) doesnt show much difference...but we are running it in a long running process, and there the gain is huge https://blackfire.io/profiles/compare/5d8fd94c-bb36-4717-b3ad-c24d87bfbf6b/graph |
at best you would drop the public blackfire comparison link so we can see exactly whats going on. |
{ | ||
$this->uriRetriever = $uriRetriever; | ||
return $this->factory->getCheckMode(); |
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.
this kind of API tells me that your factory is not really a factory (or not only that)
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.
yeah well, removed those getters, they are not really needed and not part of any interface
*/ | ||
public function validateDefinition($element, $objectDefinition = null, JsonPointer $path = null) | ||
{ | ||
$constraint = $this->getFactory()->createInstanceFor('undefined'); |
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 would name it $undefinedConstraint
to make the code more readable
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.
fixed
$this->uriRetriever = $uriRetriever; | ||
$this->factory = $factory; | ||
$this->schemaStorage = $schemaStorage; | ||
public function __construct(Factory $factory = null) |
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.
you should consider providing a BC layer for the constructor signature. Otherwise, this force to bump to 4.0 already. Supporting the old signature with a deprecation warning (building a factory from the older arguments) would make the upgrade path easier
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.
im slightly against supporting BC...i guess nobody is using custom constraints out there so its all part of the internals...im ok with a BC break here
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'm injecting a few constraints, at least until this gets merged: #308
That said, changing my client code isn't a big deal. When can we expect these PRs to get merged? What are we waiting on?
@@ -72,33 +47,13 @@ public function getUriRetriever() | |||
public function getFactory() | |||
{ | |||
if (!$this->factory) { | |||
$this->factory = new Factory($this->getSchemaStorage(), $this->getUriRetriever(), $this->checkMode); | |||
$this->factory = new Factory(); |
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.
If the factory is now always created in the constructor, there is no point in doing if (!$this->factory)
in the public getFactory
method anymore.
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.
yeah not needed, fixed
@digitalkaoz would you please rebase this PR on master and resolve conflicts. I will approve/merge/bump once all is green. |
@bighappyface ok rebased, should be all green in a few minutes! |
/** | ||
* @dataProvider getInvalidCoerceTests | ||
*/ | ||
public function testInvalidCoerceCases($input, $schema, $errors = []) |
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.
array
for 5.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.
fixed
$validator = new Validator(new Factory($schemaStorage, null, $checkMode)); | ||
$validator->check(json_decode($input), $schema); | ||
|
||
if ([] !== $errors) { |
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.
This one, too...
$validator = new Validator(new Factory($schemaStorage, null, $checkMode)); | ||
$validator->check(json_decode($input, true), $schema); | ||
|
||
if ([] !== $errors) { |
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.
one more...
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.
who is using 5.3 nowadays? anyway, fixed both ;)
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.
@digitalkaoz Composer still supports PHP 5.3 users today, and it uses this library
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.
@stof is there a plan/policy for Composer to adhere to PHP supported version lifespans?
fab3d3c
to
f452047
Compare
@shmax im getting some weird errors in my builds (which werent there before your merged PR) any idea where |
@digitalkaoz per travis the stack for this warning is
|
@staabm thanks. i had to rebase once more, should be fixed now |
Ah, sorry about that--snuck another PR in there ahead of you. I don't have any more surprises, so happy merging... |