Skip to content
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

Optimized DispatchingEntityIdParser #764

Merged
merged 1 commit into from
Oct 6, 2017

Conversation

mariushoch
Copy link
Member

@mariushoch mariushoch commented Oct 5, 2017

This made the function quite a bit faster:

14.48% 48797.778 817218 - Wikibase\DataModel\Entity\DispatchingEntityIdParser::parse

to

12.64% 42330.389 817218 - Wikibase\DataModel\Entity\DispatchingEntityIdParser::parse

when JSON-dumping 10,000 Wikidata entities.

Related to https://phabricator.wikimedia.org/T177486.

@@ -27,6 +27,10 @@ class DispatchingEntityIdParser implements EntityIdParser {
* @param callable[] $idBuilders
*/
public function __construct( array $idBuilders ) {
if ( $this->idBuilders === [] ) {
throw new InvalidArgumentException( '$idBuilders must not be empty' );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uh. I find this a little problematic. I believe this was done as it was before for a reason: The idea was to allow a setup with no custom entity types. As long as the parse method is not called, it is not a problem to have an empty ID parser.

Even if such a situation can never happen in production, this change makes this entire patch a breaking one. We could avoid this by keeping the previous handling of empty arrays.

The least minimum is to documented this as a @throws.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved back, this probably hardly has any performance impact. It mostly looked weird to me.

} catch ( InvalidArgumentException $ex ) {
// Only do this assert in case something is wrong, EntityId::splitSerialization already
// checks for string.
$this->assertIdIsString( $idSerialization );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why keep this additional check inside the catch? This looks awkward. What does this do in addition to what splitSerialization already does? Let's remove it, please.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changing it will change the Exception message slightly, but I guess that's ok.

This made the function quite a bit faster:
14.48% 48797.778 817218 - Wikibase\DataModel\Entity\DispatchingEntityIdParser::parse
to
12.64% 42330.389 817218 - Wikibase\DataModel\Entity\DispatchingEntityIdParser::parse
when JSON-dumping 10,000 Wikidata entities.

Related to https://phabricator.wikimedia.org/T177486.
@mariushoch mariushoch force-pushed the DispatchingEntityIdParser-perf branch from f0c55d6 to db79e30 Compare October 5, 2017 19:09
@mariushoch
Copy link
Member Author

Note: This is no longer breaking

@thiemowmde thiemowmde merged commit ad376ff into wmde:master Oct 6, 2017
thiemowmde pushed a commit that referenced this pull request Oct 23, 2017
This made the function quite a bit faster:
14.48% 48797.778 817218 - Wikibase\DataModel\Entity\DispatchingEntityIdParser::parse
to
12.64% 42330.389 817218 - Wikibase\DataModel\Entity\DispatchingEntityIdParser::parse
when JSON-dumping 10,000 Wikidata entities.

Related to https://phabricator.wikimedia.org/T177486.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants