Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[HttpKernel] Added support for timings in ArgumentValueResolvers#26833

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
fabpot merged 1 commit intosymfony:masterfromlinaori:feature/traceable-avr
Apr 20, 2018
Merged

[HttpKernel] Added support for timings in ArgumentValueResolvers#26833

fabpot merged 1 commit intosymfony:masterfromlinaori:feature/traceable-avr
Apr 20, 2018

Conversation

@linaori
Copy link
Contributor

@linaorilinaori commentedApr 6, 2018
edited
Loading

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets~
LicenseMIT
Doc PR~

This feature provides timings for the supports and resolve methods for each individual argument value resolver. It was already possible to see thecontroller.get_arguments timing, but it was impossible to track a possible performance issue any further without using different tools. I've explicitly added thesupports method as well, as it might otherwise hide performance issues. TheServiceValueResolver for example, does acontainer::has, which in turn might trigger a factory method, which might trigger a query for example.

Due to the feature freeze I've already added this to 4.2. If for some reason it's okay to still merge it into 4.1, I can update the upgrade files. - Changed to 4.1

Without performance issue

image

With performance issue

image

slootjes, sstok, yceruto, and ro0NL reacted with thumbs up emojisstok reacted with hooray emoji
*/
publicfunctionsupports(Request$request,ArgumentMetadata$argument):bool
{
$method =\get_class($this->inner).'::'.__FUNCTION__;
Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Could also just do$method = \get_class($this->inner).'::supports'; and resolve for the other. Not sure what is preferred. Opinions?

sstok reacted with thumbs up emoji
Copy link
Contributor

Choose a reason for hiding this comment

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

👍for__FUNCTION__

@fabpot
Copy link
Member

4.1 is still open for small additions.

@linaori
Copy link
ContributorAuthor

I've updated the changelogs to be for 4.1

@ogizanagiogizanagi added this to the4.1 milestoneApr 6, 2018
HttpKernel
----------

* Added the `Symfony\Component\HttpKernel\Controller\ArgumentResolver\TraceableValueResolver`
Copy link
Contributor

Choose a reason for hiding this comment

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

There is no upgrade path here 😄

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Should I remove it in that case? It doesn't cause harm to add it, but it's not really of any value to developers as it's primarily internal.

Copy link
Contributor

Choose a reason for hiding this comment

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

That's what I meant actually. There is no BC break to document here, no upgrade path. We don't mention features inUPGRADE files 😄

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

done 😄

*/
publicfunctionsupports(Request$request,ArgumentMetadata$argument):bool
{
$method =\get_class($this->inner).'::'.__FUNCTION__;
Copy link
Contributor

Choose a reason for hiding this comment

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

👍for__FUNCTION__

$resolvers =$this->findAndSortTaggedServices($this->argumentValueResolverTag,$container);

if ($container->getParameter('kernel.debug') &&class_exists(Stopwatch::class)) {
foreach ($container->findTaggedServiceIds('controller.argument_value_resolver')as$id =>$tags) {
Copy link
Member

Choose a reason for hiding this comment

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

'controller.argument_value_resolver' =>$this->argumentValueResolverTag


if ($container->getParameter('kernel.debug') &&class_exists(Stopwatch::class)) {
foreach ($container->findTaggedServiceIds('controller.argument_value_resolver')as$id =>$tags) {
$container->register($id.'.traceable', TraceableValueResolver::class)
Copy link
Member

Choose a reason for hiding this comment

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

we are used todebug.$id

foreach ($container->findTaggedServiceIds('controller.argument_value_resolver')as$id =>$tags) {
$container->register($id.'.traceable', TraceableValueResolver::class)
->setDecoratedService($id)
->setArguments(array(newReference($id.'.traceable.inner'),newReference('debug.stopwatch')));
Copy link
Member

Choose a reason for hiding this comment

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

this binds the feature to FrameworkBundle as it's the one registeringdebug.stopwatch. I would make itnull if invalid and instantiatesStopWatch in the TraceableValueResolver constructor if not injected

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

The class is kinda useless if null is inserted though 😅 there's no way of fetching the stopwatch. The only thing that happens, is that it doesn't crash on NULL.

return;
}

$resolvers =$this->findAndSortTaggedServices($this->argumentValueResolverTag,$container);
Copy link
Member

Choose a reason for hiding this comment

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

assignment does not seem necessary, leftover?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

It's actually being used fornew IteratorArgument($resolvers). I initially wasn't able to use this as I needed the id, but casting the reference to a string gives me exactly that, saving a call to the container.

Copy link
Member

Choose a reason for hiding this comment

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

oops, missed the loop!

$id = (string)$resolverReference;
$container->register('debug.'.$id, TraceableValueResolver::class)
->setDecoratedService($id)
->setArguments(array(newReference('debug.'.$id),newReference('debug.stopwatch', ContainerInterface::NULL_ON_INVALID_REFERENCE)));
Copy link
Member

Choose a reason for hiding this comment

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

should be"debug.$id.inner"?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Woops, I think I've removed too much 😅

@linaori
Copy link
ContributorAuthor

Service definitions should be fixed now, tests are passing 👍 My PC only froze for 10 minutes after which I rebooted via the on/off button, due to a minor recursion issue I created during the process.

Copy link
Member

@chalasrchalasr left a comment
edited
Loading

Choose a reason for hiding this comment

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

👍 Could have a line in the http-kernel changelog

@linaori
Copy link
ContributorAuthor

@chalasr I removed the line where I mentioned adding it based on feedback earlier. I can put something back in there if desired. What were you thinking of?

@chalasr
Copy link
Member

@iltar I mean only the CHANGELOG file, not upgrade ones :)

@linaori
Copy link
ContributorAuthor

Something in the form of:Added the ability to profile individual argument value resolvers via the Symfony\Component\HttpKernel\Controller\ArgumentResolver\TraceableValueResolver?

@chalasr
Copy link
Member

👌 for me

@fabpot
Copy link
Member

Thank you@iltar.

sstok reacted with hooray emoji

@fabpotfabpot merged commit1c0d892 intosymfony:masterApr 20, 2018
fabpot added a commit that referenced this pull requestApr 20, 2018
…eResolvers (iltar)This PR was squashed before being merged into the 4.1-dev branch (closes#26833).Discussion----------[HttpKernel] Added support for timings in ArgumentValueResolvers| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | ~| License       | MIT| Doc PR        | ~This feature provides timings for the supports and resolve methods for each individual argument value resolver. It was already possible to see the `controller.get_arguments` timing, but it was impossible to track a possible performance issue any further without using different tools. I've explicitly added the `supports` method as well, as it might otherwise hide performance issues. The `ServiceValueResolver` for example, does a `container::has`, which in turn might trigger a factory method, which might trigger a query for example.~~Due to the feature freeze I've already added this to 4.2. If for some reason it's okay to still merge it into 4.1, I can update the upgrade files.~~ - Changed to 4.1##### *Without performance issue*![image](https://user-images.githubusercontent.com/1754678/38416250-6cf45528-3994-11e8-91d4-2472c97c6c50.png)##### *With performance issue*![image](https://user-images.githubusercontent.com/1754678/38416266-7966eb7c-3994-11e8-9dc5-a99daa8f9a69.png)Commits-------1c0d892 [HttpKernel] Added support for timings in ArgumentValueResolvers
@fabpotfabpot mentioned this pull requestMay 7, 2018
fabpot added a commit that referenced this pull requestMay 14, 2018
…atory (ogizanagi)This PR was merged into the 4.1 branch.Discussion----------[HttpKernel] Make TraceableValueResolver $stopwatch mandatory| Q             | A| ------------- | ---| Branch?       | 4.1 <!-- see below -->| Bug fix?      | no| New feature?  | no <!-- don't forget to update src/**/CHANGELOG.md files -->| BC breaks?    | no     <!-- seehttps://symfony.com/bc -->| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->| Fixed tickets |#26833 (comment)   <!-- #-prefixed issue number(s), if any -->| License       | MIT| Doc PR        | N/AI understand why this was suggested in#26833 (comment), but as stated by@iltar , I don't think it makes sense to register a traceable resolver instantiating a Stopwatch itself, as there is no way to fetch it and wouldn't be a shared instance, probably defeating the feature and registering a useless decorator.Instead, let's make the stopwatch mandatory and make the service id to use in the pass configurable.Commits-------585ae7c [HttpKernel] Make TraceableValueResolver $stopwatch mandatory
fabpot added a commit that referenced this pull requestMay 14, 2018
…voke controllers method (ogizanagi)This PR was merged into the 4.1 branch.Discussion----------[HttpKernel] Fix services are no longer injected into __invoke controllers method| Q             | A| ------------- | ---| Branch?       | 4.1 <!-- see below -->| Bug fix?      | yes| New feature?  | no <!-- don't forget to update src/**/CHANGELOG.md files -->| BC breaks?    | no     <!-- seehttps://symfony.com/bc -->| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->| Fixed tickets |#27208   <!-- #-prefixed issue number(s), if any -->| License       | MIT| Doc PR        | N/A_TL;DR:_ The `RemoveEmptyControllerArgumentLocatorsPass` is the one adding the `Controller::_invoke` => `Controller` shortcut missing from the service locator. It isn't properly executed on some cases. This fixes it.Since#26833, the resolvers are decorated by a `TraceableValueResolver`, which usually isn't much an issue to deal within passes. But the `RemoveEmptyControllerArgumentLocatorsPass` happens late (`TYPE_BEFORE_REMOVING`), when decoration inheritance is already resolved, so accessing `$controllerLocator = $container->getDefinition((string) $serviceResolver->getArgument(0));` isn't accessing the controller locator, but the decorated service instead.Commits-------ee44903 [HttpKernel] Fix services are no longer injected into __invoke controllers method
symfony-splitter pushed a commit to symfony/http-kernel that referenced this pull requestMay 14, 2018
…voke controllers method (ogizanagi)This PR was merged into the 4.1 branch.Discussion----------[HttpKernel] Fix services are no longer injected into __invoke controllers method| Q             | A| ------------- | ---| Branch?       | 4.1 <!-- see below -->| Bug fix?      | yes| New feature?  | no <!-- don't forget to update src/**/CHANGELOG.md files -->| BC breaks?    | no     <!-- seehttps://symfony.com/bc -->| Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files -->| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->| Fixed tickets | #27208   <!-- #-prefixed issue number(s), if any -->| License       | MIT| Doc PR        | N/A_TL;DR:_ The `RemoveEmptyControllerArgumentLocatorsPass` is the one adding the `Controller::_invoke` => `Controller` shortcut missing from the service locator. It isn't properly executed on some cases. This fixes it.Sincesymfony/symfony#26833, the resolvers are decorated by a `TraceableValueResolver`, which usually isn't much an issue to deal within passes. But the `RemoveEmptyControllerArgumentLocatorsPass` happens late (`TYPE_BEFORE_REMOVING`), when decoration inheritance is already resolved, so accessing `$controllerLocator = $container->getDefinition((string) $serviceResolver->getArgument(0));` isn't accessing the controller locator, but the decorated service instead.Commits-------ee44903 [HttpKernel] Fix services are no longer injected into __invoke controllers method
@linaorilinaori deleted the feature/traceable-avr branchFebruary 8, 2019 13:37
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@fabpotfabpotfabpot approved these changes

@chalasrchalasrchalasr approved these changes

+1 more reviewer

@ogizanagiogizanagiogizanagi left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

4.1

Development

Successfully merging this pull request may close these issues.

5 participants

@linaori@fabpot@chalasr@ogizanagi@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp