Description

I consume API responses in parallel that can be very big and also multiplex the response handling using the Symfony HTTP client which works great. You can run into memory limits easily which is understandable and which I can tune by selecting which request/responses to process in parallel. This is under my control.

But I've noticed that the even bigger problem for the memory limit is the tracing of the profiler and the SQL logger in the dev environment. So things can easily work in prod mode but in dev mode even twice the amount of memory won't be enough. This is kind of annoying and makes it hard to estimate how much memory is needed or how to tune things when developing.

There are two memory offenders:

1. http tracing which adds the response body to the profiler. This can be disabled manually with

$this->client->request('GET', '...', [
    'extra' => ['trace_content' => false],
]);

2. Since I cache the data in an SQL database the DoctrineDbalAdapter will execute SQL statements with big params. So the logging additionally also consumes alot of memory. In this past it seems there was a way to disable SQL logging for certain parts by removing the SqlLogger on the connection configuration. See Recommended approach for disabling the logging in some occurrences doctrine/DoctrineBundle#787 or https://stackoverflow.com/questions/35192173/how-to-disable-query-logging-in-console-while-load-doctrine-fixtures
   This does not seem to work anymore since Introduce logging middleware doctrine/dbal#4967 which always logs the sql statements.

So even if there were workarounds for these problems, it still requires alot of debugging and manual solutions.
I think it should be possible to have good profiling and logs while not overdo it to prevent out of memory issues.
What I would propose:
The http client and the cache component would measure the memory consumption in debug mode when doing http requests or inserting cache items and if the used memory is approaching the memory limit, then they should automatically disable content tracing and logging for those items. Or it could at least truncate the data.

This approach would probably also work for other parts of the dev profiling. As the http client and cache can process large amounts of data, I think this is a good first step.