Skip to content

Lazy loading for arguments #429

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

Closed
wants to merge 3 commits into from
Closed

Lazy loading for arguments #429

wants to merge 3 commits into from

Conversation

mad-ice
Copy link

@mad-ice mad-ice commented Jan 7, 2019

Hi!

This pull request ensures that field arguments can be lazy loaded in the same manner as fields, which should improve performance quite a bit. I've ran a majorly tiny benchmark on the performance impact and found out that this change decreased our schema build time from 28ms to 3ms.

I'd like to get some help on testing this feature as I'm not familiar with maintaining automated tests and got lost trying to find the right place to add them.

And, of course, a big thank you for the amazing library!

@mad-ice mad-ice changed the title Lazy loading for argument Lazy loading for arguments Jan 7, 2019
@mad-ice
Copy link
Author

mad-ice commented Jan 7, 2019

Might be related to @shmax's issue: #425

.gitignore Outdated
@@ -4,3 +4,4 @@ composer.phar
phpcs.xml
phpstan.neon
vendor/
.idea/
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hi, for this is not project related you should add it to your global gitignore.

Copy link
Author

Choose a reason for hiding this comment

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

Didn't know that existed, thanks!

@shmax
Copy link
Contributor

shmax commented Jan 7, 2019

Ah, this looks promising! I have to head to work, but when I get back I'll pull your branch and run my profiler. Very excited to see the results...

@@ -3,4 +3,4 @@ composer.lock
composer.phar
phpcs.xml
phpstan.neon
vendor/
vendor/
Copy link
Collaborator

Choose a reason for hiding this comment

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

we're missing a line feed

If you're using Jetbrains IDE, it can be automatically handled by Editor -> General -> Other

image

}

if (! is_array($config)) {
throw new \InvalidArgumentException('$config must be an array or a callable which returns such an array.');
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
throw new \InvalidArgumentException('$config must be an array or a callable which returns such an array.');
throw new \InvalidArgumentException('"$config" must be an array or a callable which returns such an array.');

@spawnia
Copy link
Collaborator

spawnia commented Jun 10, 2019

@mad-ice to move this issue along, you can add a test to https://github.com/webonyx/graphql-php/blob/master/tests/Type/DefinitionTest.php

Check out https://github.com/webonyx/graphql-php/blob/master/CONTRIBUTING.md for more information on the dev tooling. Try running composer check-all on the project.

{
if (is_callable($config)) {
Copy link
Contributor

@shmax shmax Oct 16, 2019

Choose a reason for hiding this comment

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

Sorry for the long delay, but as promised I tried out your changes. So far I don't quite understand how this changes things; createMap is called by the FieldDefinition constructor, and then you just check to see if $config is callable, and if it is you immediately call it? Where do the savings come in?

I tested this by converting a few of the args on my top-level Query fields to functions, and stuck breakpoints inside them; they get called immediately.

What am I missing, here? Where does the "lazy" happen?

Copy link
Contributor

Choose a reason for hiding this comment

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

I just POC'ed my own full lazy loading concept; so far seems to work pretty well. I'll try to put together a PR by the end of the week.

@vladar
Copy link
Member

vladar commented Nov 3, 2019

Thanks for the PR. But we will likely go the path suggested in #557 which addresses an issue with lazy loading of individual types

@vladar vladar closed this Nov 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants