[upstream] Too many calls to \Symfony\Component\Serializer\Serializer::getNormalizer()

Per

such as checking the normalizer for each data type that it encounters.

this is definitely not a bug. In fact, there are zero ->getNormalizer( calls in the JSON API code base.

#3014283: Use ResourceTypeFields to statically determine the field normalizer will have the nice side-effect to fix this today.

The blackfire profile at #3014232-10: [regression] ResourceTypeRepository is significantly slower in JSON:API 2, becomes noticeable when handling hundreds of interlinked resources confirm this problem again, 9.74% of exclusive wall time is spent in \Symfony\Component\Serializer\Serializer::getNormalizer()!

That would IMHO make this worth working around in JSON:API. But hopefully #3014283: Use ResourceTypeFields to statically determine the field normalizer will solve this at a higher level, which would mean we wouldn't need to work around it :)

This is a core issue for the same concern ^

I do think there are meaningful and workable actions we can take in the JSON:API module to fix this w/o requiring upstream changes, but #3014283: Use ResourceTypeFields to statically determine the field normalizer is not yet one of them.

I disagree, #3014283: Use ResourceTypeFields to statically determine the field normalizer is both a meaningful and a workable action to solve this problem.

#3017291: \Symfony\Component\Serializer\Serializer::getNormalizer() is slow was definitively shot down by both Drupal core and Symfony: Drupal 8 core cannot update to Symfony 4, and Symfony folks refuse to port the bugfix (they call it a "feature") to Symfony 3.

#3014232: [regression] ResourceTypeRepository is significantly slower in JSON:API 2, becomes noticeable when handling hundreds of interlinked resources was fixed yesterday.

AFAICT that leaves #3014283: Use ResourceTypeFields to statically determine the field normalizer as the next actionable thing. I think that #3014283-28: Use ResourceTypeFields to statically determine the field normalizer means that @gabesullice is +1 now, but I'm not entirely sure. But I think @gabesullice was perhaps pointing out that #3014283 needs #3014277: ResourceTypes should know about their fields to land first?

I think that #3014283-28 means that @gabesullice is +1 now, but I'm not entirely sure

+1 to what? I don't know what you're referring to.

I disagree, #3014283: Use ResourceFieldInterface to statically determine the field normalizer is both a meaningful and a workable action to solve this problem.

It's a meaningful and workable action, but it won't solve this problem. It will make it somewhat better.

Which is essentially what you said in #3014283-27: Use ResourceTypeFields to statically determine the field normalizer:

Wait. I agreed that we won't ever be able to solve the problem #3011497: [upstream] Too many calls to \Symfony\Component\Serializer\Serializer::getNormalizer() beyond a certain point. This issue will solve it for as much as we can do.

I think that there are more things that we can do. I have yet to collect and synthesize my thoughts about what I believe those things are though.

+1 to what? I don't know what you're referring to.

In #9 on Nov 30 you linked to #3017291: \Symfony\Component\Serializer\Serializer::getNormalizer() is slow, suggesting that should happen as a solution for the cause rather than the symptom. In #3014283-28: Use ResourceTypeFields to statically determine the field normalizer you seemed to confirm @e0ipso in #3014283-27: Use ResourceTypeFields to statically determine the field normalizer that #3017291 cannot happen due to Drupal vs Symfony version and backporting constraints. And that #3014283 is therefore the only viable way forward out of that performance problem.

I think that there are more things that we can do.

Okay, so you think we can do even more. Great! 😀 But do you think that #3014283: Use ResourceTypeFields to statically determine the field normalizer is:

1. at least a great interim step
2. or, ideally, something that has to happen anyway?