Is this also the case on 3.2+? Because here I saw massive performance issues in dev mode, but have been unable to trace the cause.

This patch cannot be merged as is because it forces one single list of logs, thus defeats the purpose of using objects for scope isolation.
Yet, as I understand the issue, all sub-requests have the same logs, and we still serialize them several times?
Also, which exact Symfony version was the profile done with? Can you try v3.3.5 if that was an earlier version?

I profile v3.3.5 and get same resulthttps://blackfire.io/profiles/76d6907f-ef47-4c5f-9fea-9a73c926e2f1/graph.
Yes, all sub-requests have the same logs, and we still serialize them several times.
It problems also exist on v2.8.* Our application used 2.8.13. We noticed that debug toolbar not showing (error not found 404) on some heavy pages. The reason was that serialize and collects logs for each sub-request take a lot of time. Then we could not find a more correct solution than thishttps://github.com/orocrm/platform/blob/master/src/Oro/Bundle/LoggerBundle/DataCollector/LoggerDataCollector.php

What's the effect of this patch?

--- a/src/Symfony/Component/HttpKernel/EventListener/ProfilerListener.php+++ b/src/Symfony/Component/HttpKernel/EventListener/ProfilerListener.php@@ -105,6 +105,10 @@ class ProfilerListener implements EventSubscriberInterface      public function onKernelTerminate(PostResponseEvent $event)     {+        if ($gc = gc_enabled()) {+            gc_disable();+        }+        try {             // attach children to parents             foreach ($this->profiles as $request) {                 // isset call should be removed when requestStack is required@@ -122,6 +126,11 @@ class ProfilerListener implements EventSubscriberInterface              $this->profiles = new \SplObjectStorage();             $this->parents = new \SplObjectStorage();+        } finally {+            if ($gc) {+                gc_enable();+            }+        }     }

We've been experiencing similar issues on certain pages in 3.2, though it doesn't necessarily happen every request on that page, it simply gives an error opening the profile "randomly".

Wondering: what would be the downside of settingframework.profiler.only_master_requests to true?

Of course it workframework.profiler.only_master_requests: true because hides cause of the problems.
After disable gc:https://blackfire.io/profiles/e0dc05e2-8769-4a29-a220-5228599e9c47/graph
I think we should not show the same list of logs for each sub-request and master request. For example if I open debug toolbar for doctrine query I will see different count of sql query for each sub-request, but not for logs toolbar.
I will try to implement this, It also should be fix performance because the same log will not be processed many times for each sub-request

This won't fix the issue of having the logs serialized several times, yet it'd be really nice if you could revert that patch above (adding gc_disable), and try#23644 instead. What's the resulting profile?

It is improve performance by execute time, but not memory
Comparison resulthttps://blackfire.io/profiles/compare/94da04c4-56a4-48f0-93fe-9a8b25fc28d0/graph

Thanks,
Vladimir

New profile welcomed, I pushed a new patch on#23644 :)

It has improved performance for VarDumperhttps://blackfire.io/profiles/30521d32-392e-435a-8f01-af4492df0f55/graph
Thank you!

I don't understand the memory increase. Can you please do a last profile with the new patch on the PR see if it improves things?

The memory increase is still observed again after merge#23644
Diffhttps://blackfire.io/profiles/compare/67678cc5-6ffa-4762-b6d2-c2906749904f/graph
3.3-dev before mergehttps://blackfire.io/profiles/20084aa3-c6f1-48eb-84df-d68ed6bd77a4/graph
3.3-dev after merge#23644https://blackfire.io/profiles/7566ac39-b583-4280-a26d-a1ed3f41bf70/graph
I also pushed my test application so that you can be sure of ithttps://github.com/vtsykun/test-symfony-application