I noticed a similar slowdown. See the profile of the same page of a complex Symfony app using 3.2 and 3.3 versions:

3.2.9

3.3.2

Main differences

/cc @nicolas-grekas

This means too much data is being cloned. Can you think of any object that could be collected but should be skipped because it's not displayed? There should be some to explain the difference.

I am also seeing a massive difference in memory usage. My php memory limit was previously set to 64mb, since upgrading from 3.2.9 to 3.3.2 I've had to increase this to 160mb to avoid getting out of memory errors. I have tested on a few different Symfony versions, and this change occurs between 3.3.0 and 3.3.1.

I also noticed that the performance tab shows about 50% increased peak memory usage, all consumed by the ProfilerListener.

With a lower memory limit, an out of memory exception always occurs at https://github.com/symfony/symfony/blob/3.3/src/Symfony/Component/HttpKernel/DataCollector/DataCollector.php#L44

The memory usage in production environment is unaffected.

I am currently running PHP 5.5.38.

Performance Page - Master request

If I check the Performance page of a Sub Request (widgetGenderAction), I can see that Total execution time doesn't correspond to the processing of the sub request (11ms). Is it normal? It does not match either the total execution time of Master Request (825ms or the total of Sub Request time 179 ms).

If I click on the Routing page of Sub Request, I got an OutOfMemory exception (on php 7.1.6 with memory_limit=128mb)

When I increase the memory limit, I got:

None route match for Sub Requests so maybe the Routing data collecting could be avoid here?

Well, the timing of a request does not include the time spent in ProfilerListener (this is a chicken and egg issue: how do you measure the time until after you are done saving the result of the measure ?).

And the issue here seems to be that the Symfony initialization time is add in subrequests too, while it is actually paid by the master request only (you pay it once per process only).
The collector would need to skip collecting this part of the timing when collecting info for a subrequest.

And this matches numbers: 293ms is 282ms (SF initialization, copied from the master request by mistake) + 11ms (time collected for the subrequest)

@stof Ok understood but in that case the figure in master request is not accurate (5ms). Check my screenshot of Master Request.

What is your opinion about the routing part?

Not sure if related to this, but the files generated by the profiler (var/cache/dev/profiler/*) are HUGE. It takes more than 2 MB per request in some of my applications. Other users have complained about this too.

Hi!

We have same issue, when upgrading to Symfony 3.3.x.

For example I've got a page with a form field EntityType, which loads about 500 entities to render a select dropdown, now profiler generates a >50Mb file and 404 debug toolbar error appears.

If I downgrade to Symfony 3.2.x, same page, generates a 1.8Mb profiler file.

Profiler is pretty slow after upgrading to Symfony 3.3. Furthermore, storage space is gigantic. At some pointed it reached over 100 GB. The only thing we can do is removing /cache/dev/profiler/ at the end of the day. This behavior makes the profiler unworkable for now.

I don't know if this is a bug or a feature that must be reverted, but I've added the "Critical" label because fixing this should be our top priority. Thanks!

Please post one of these big files.

Profiler directory reached 110 GB today:

@XWB: You are pressing F5 too much :P

Well it never was an issue prior to Symfony 3.3 ;)

@nicolas-grekas What file would you like to see? Each directory within /cache/dev/profiler/ contains a lot of subdirectories, each being 454 MB in size:

Please, any update? I can't upgrade to Symfony 3.3 :(

@markitosgv it's not progressing much because we don't have any reproducible code. If you can publish such of those files or publish a repo where this error occurs I'm sure it would be solved in no time :)

Maybe it is linked to the Symfony's web server? I know that sometimes you can get extremely slow performance out of it (like when rendering PDFs with KNPSnappyBundle). Also, this drop is new, since I was able to run a project on my PC on 3.3.0 without any issues when it was initially released.

Maybe it is linked to the Symfony's web server? I know that sometimes you can get extremely slow performance out of it (like when rendering PDFs with KNPSnappyBundle).

I'm seeing similar issues when using Apache.

For us the problem is most noticeable on Sonata admin pages (3.20.1).
Using Twig 2.3 instead of 2.4 makes it better, it's still a noticeable performance drop.

Using Symfony 3.3.2, Apache.

We are using MongoDB, Nginx and PHP 7. You can try with an EntityType in a form (in our case DocumentType) with ~400 results for example to notice that.

Oh yeah, I forgot to mention I do have a lot (~280) of depreciations messages out of Twig, since the libraries I use still use it in version 1.20-ish and I can not switch to 2.x. Could be another lead? PHP 7.1 btw.

Please share one of the big files generated by the profiler.

@nicolas-grekas I have a ~400MB profiler file I could share, but I the question is where do I send it? Is there any sensitive data in those files I should be worried about, or can I just upload it to some file sharing service without worry?

Hi, Same issue here. Memory usage is increasing massively.
We can't upgrade to 3.3

Hi all, could you please try #23413 and report any improvement?

@nicolas-grekas Thx, it seems better, but I feel like it's still slower than 3.3.2. Will wait for others to post benchmarks.

See #23415, Backfire profiles welcomed.

Hi guys, for me problem with Symfony 3.3.4 still persists.

Same page, with symfony 3.2.9 works :/

In fact, this maybe related to a high number of deprecations, not only to the way the data is collected in 3.3. Is that plausible? Can you post a screenshot of the profiler deprecation panel?

This is another page deprecations info:

But, I think it's not about deprecations, look:

...
->add(
    'activeOrganization',
    DocumentType::class,
    [
        'label'       => 'Active Organization',
        'class'       => Organization::class,
        'attr' => [
            'placeholder' => 'userContact.activeOrganization.placeholder',
        ],
        'query_builder' => function ($qb) {
            return $qb->createQueryBuilder()->select('contact.name')->select('owner')->field('owner')->prime(true);
        },
    ]
)
...

If I put a limit in the query, like 100, It works ok. I know this is not the best way to show a select with a huge collection of entities, but it's ok for this purpose.

I have this issues on a page where there's a query returning a single record, so I do not think it is related to a lot amount of data being fetched from the database.

Please open specific issue, related to the Form panel it looks like?

In fact, this maybe related to a high number of deprecations, not only to the way the data is collected in 3.3. Is that plausible? Can you post a screenshot of the profiler deprecation panel?

I have only 1 deprecation notice in my application.