I'm unfamiliar with what you're doing but if my assumption is correct, it means that you don't close the request/terminate symfony? Could you explain a bit more about the challenge you're facing?

it means that you don't close the request/terminate symfony

What do you mean with 'close the request' or 'terminate symfony'? We do close the request by calling Kernel::terminate($request, $response);, but we do not shutdown the Kernel, which should not be necessary as we need the kernel for further requests.

@marcj not shutting down the kernel also means that you reuse the same Container instance all the time. This is what could cause issues in several places (and it is exactly what causes issues here). Several collector services are stateful, and so would keep the data and mix them with the next request in the profiler. You will also have issues with the FingersCrossedHandler of Monolog for instance.

Rather than trying to list all places where a cleanup would be necessary at the end of the request (which is quite painful as there is no such listing today, and any bundle could contain such a place), have you tried to look at the performance impact of calling $container->reset() to perform a complete cleanup (you will still need to reset the start time though) ? It may be much easier for now, if the perf impact is acceptable.
Note that ResettableContainerInterface is only available as of Symfony 2.8, but you can detect whether the container supports the feature by checking whether it implements the interface.

Instead of doing https://github.com/php-pm/php-pm-httpkernel/blob/master/Bootstraps/Symfony.php#L90-L99 I tried $app->getContainer()->reset() but this breaks with the exception You have requested a synthetic service ("kernel"). The DIC does not know how to construct this service. after the second request.
I also tried $app->shutdown(), but this makes it terrible slow again.

ah right, the kernel sets itself only during the initial creation. Try this then:

$app->getContainer()->reset();
$app->getContainer()->set('kernel', $app);

Rather than trying to list all places where a cleanup would be necessary at the end of the request (which is quite painful as there is no such listing today, and any bundle could contain such a place)

It is indeed painful and quite a bit of work, but I think it's the only way to keep this whole approach alive and to keep the good performance. But I believe it's time to make this list now :) Maybe PHP-PM is the starting shot for it.

I just tried the latest comment with set('kernel', $app), this works, but makes it again very slow. I guess it's almost equal to shutdown except the boot calls to all bundles (which is important when you reset the container, at least in one of my applications). I guess resetting the container is not the right way to go, although I'd be perfect if it wouldn't hurt the performance so much as it could be more compatible. However, I guess I need to investigate deeper.

Any other hints where I can reset the profiler?

Ok, I know now why those stats don't get reseted. The DataCollectorInterface has only the method collect which most DataCollector implementations have in a way implemented that they don't delete the stuff when collect is called. This would be currently the only way to keep the memory clean, but would not be perfect, as a second call would return reseted data. A new method DataCollectorInterface::clean would solve that issue, but would obviously take too much time until all implementations have updated, so the only way is currently to reset the services and dependencies in the container.

I have done now some really nasty hacks, but works so far.
php-pm/php-pm-httpkernel@d6199a5#diff-4e4aadfdc2edbd7dfe3479c6259178eaR86

What do you guys think about making this more pretty by introducing some new API methods to the DataCollector stuff? FrameworkBundle/ProfilerListener could call a method like clear on onKernelTerminate which basically cleans all data collectors.

You could solve it with something like DataCollectorResetInterface::reset().

@marcj maybe you can try to reset state of data collectors using reflection?

@marcj Making Symfony work better with solution like php-pm is always a good idea. I spent a lot of time a few years back to make sure that Symfony does not leak memory, and we should continue this work. Adding some clean method in the master branch would not solve your immediate problem but makes Symfony stronger in the long term, which is great.