RelatedCollectionLinkNormalizer performance improved

[pmattmann]

Function getRelatedCollectionHref is called several times for the same relation

• try-catch removed
• cache per relation if no URI can be calculated for it anyway (instead of trying again and again)

Old:

• all activities
  
• activities of one camp
  

New:

• all activities
  
• activities of one camp
  

New2:

• all activities
  
• activities of one camp
  

#6461

[carlobeltrame]

Is the array return really faster than the exception? If so, then facepalm PHP...
But did you test whether the performance is also improved similarly with only the caching part?

[pmattmann]

Is the array return really faster than the exception? If so, then facepalm PHP... But did you test whether the performance is also improved similarly with only the caching part?

As far as I know, it is faster in most languages if you don't need exceptions for the control flow.
You can find a few measurements for PHP here:
https://php.watch/articles/php-exception-performance#results

[BacLuc]

When starting to write performance optimized code, there is always the tradeof between readability (here the inconsistency with the php way of writing code and that we use exceptions in the other places) and the gained performance.

A way for this would be:

1. Benchmark this endpoint (measurement done)
2. Show, that this is the crucial part were the performance can be gained, e.g. with a profiler. (Maybe there is a simpler place where we can gain more)
3. optimize the performance here
4. Benchmark again and show that it improved
5. Write a test that enforces this maybe uncommon style
6. Look how it behaves in production.

But i would say this is ok here and we look how the request time behaves when we have it running with real users against the real database.

But maybe there is more to gain with other configurations of the frankenphp container, as can be seen here:

• Analyse changes in the performance between php-fpm setup and frankenphp in prod #5692

[pmattmann]

When starting to write performance optimized code, there is always the tradeof between readability (here the inconsistency with the php way of writing code and that we use exceptions in the other places) and the gained performance.

A way for this would be:

1. Benchmark this endpoint (measurement done)
2. Show, that this is the crucial part were the performance can be gained, e.g. with a profiler. (Maybe there is a simpler place where we can gain more)
3. optimize the performance here
4. Benchmark again and show that it improved
5. Write a test that enforces this maybe uncommon style
6. Look how it behaves in production.

But i would say this is ok here and we look how the request time behaves when we have it running with real users against the real database.

But maybe there is more to gain with other configurations of the frankenphp container, as can be seen here:

• Analyse changes in the performance between php-fpm setup and frankenphp in prod #5692

I completely agree with the procedure you described!
That's exactly what I did.

Here is the initial measurement (XDebug Profiler) of localhost:3000/api/activities.jsonhal

RelatedCollectionLinkNormalizer::getRelatedCollectionHref() is clearly a time consuming operation.

Here are the results after implementing the cache:

[pmattmann]

@BacLuc
If you agree with my last adjustments, please merge.
thx