so do you see any events taking a lot longer time in the profiler? and is this in the dev or prod env? make sure to test both.

I tested both, it's the same performance drop. Well, there is a slight increase in kernel.response from 3ms to 5ms and also the memory seems to come from that event. Am I reading the timeline correctly that the Doctrine service reports being done in 2ms, however the timeline stretches far beyond that?

According to your timeline, the memory consumption of Doctrine exploded from 5.2 MB to 17.8 MB. Could that be the origin of the problem?

Be careful that the Doctrine blocks in the timeline are the DBAL queries, not the whole Doctrine logic (the ORM takes some time too).

I suggest doing a bloackfire.io profiling to find the bottleneck (it is in public beta now, so you can get access on it)

blackfire.io being the correct URL :)

indeed.

Hi,
Do you have new things about this issue ? it interests me ! :)

@jb18 : we're still waiting for someone to share some more profiling information.

Sorry, I haven't got the time yet to analyze this more thoroughly. It seems though that with 2.6.1 there is still a performance drop, but not as pronounced. I will probably not get to an in-depth analysis before Christmas...

@YetiCGN Thanks :). Ideally, with Blackfire, it should be quite easy and useful, when you have some time.

@YetiCGN i have the same problem and revert symfony to the latest 2.5 version

@YetiCGN @aLkRicha I'll be happy to help to analyse the profiling results. Could any of you provide a simple app reproducing the problem, or perhaps xhprof profiles (before/after)?

@YetiCGN can you try with these settings please:

# app/config/parameters.yml
parameters:
    # ...
    doctrine.server_version: 5.6

If you're using the latest Doctrine 2.5, that will free you from one db call that Doctrine added recently for fetching the server version (when it is not already configured explicitly).
Does that fix the perf pb?

Little side note, in Symfony 2.6.4 with Doctrine DBAL 2.5.1 the performance is "back" to 2.5.7 levels. I have not yet begun to dig into the reasons for this.

Thanks for all your feedback! I will leave this open in case I have a spare weekend sometime in the future to get to the bottom of this.

@YetiCGN Thanks for the feedback. I'm going to close it now and feel free to reopen when you have more information. Thanks.

i have the same performance problem and reverted back to 2.5.x
Doctrine DBAL 2.5.1 didn't change anything
The performance problem is actually noticable too on a simple login page without any db call.
For me it s not 100ms slower but it s about 2 time slower (exemple 3000ms become 6000ms...) when there is db call and 1.5 time slower on the login page

@bdujon we can't do much without your help. Would you be able to provide either of the following:

• a (preferably simplified) code to demonstrate the problem?
• a blackfire profile (or a profile coming from any other profiling tool)?

@jakzal sorry for the late answer for me the solution is just to not use sf2 > 2.5.x.
I just tried to reproduce it with the new symfony installer and i reproduce it on /demo/hello/World of the AcmeDemoBundle. I thought it was coming from doctrine but it s not even that.
symfony 2.5.10 : 267ms / 13.8mb
symfony 2.6.6 : 535ms / 14mb
sf 2.6.x just seems 2 time slower than sf 2.5.x
i get that on windows 8 with php build in webserver on dev environment

i cant use blackfire as i m on windows.

@bdujon since you managed to reproduce it, if you put the code in a public repo I'll have a look.

@bdujon can you confirm this is in prod env (not debug)?

wait, are you saying it's slower on the demo without any changes?

On my Windows 8 PC, things are a little bit slower in production (a fresh installation with just AcmeDemoBundle registration and routing moved to prod), but not as dramatic as @bdujon:

• 2.5.10 /demo/hello/World: 269 ms
• 2.6.6 /demo/hello/World: 304 ms

(please note that I ran the page multiple times and all results were consistent around 300 for 2.6 and 260-270 for 2.5)

OS X, PHP 5.5.14, prod mode:

• 2.5.10 - 63.5ms, 7.94MB
• 2.6.6 - 67ms, 8.33MB

i m sorry i can't reproduce it on AcmeDemoBundle anymore. Now the timer are the same ... (i guess i got tricked by my laptop cpu that must have changed its speed while testing on different page.. each time ... ! )
But i reproduce it each time on a complex page with the timer going from 1000ms on 2.5 to 3000ms on 2.6.
I ll try to narrow it down.

The problem was never on prod environment but only on dev environment.

ok i think i found it. It s at least coming from the choice type form renderer.
Here s a simple example to reproduce it
controller :

public function listAction(Request $request)
{
    $form = $this->createFormBuilder()
        ->add('list', 'choice', ['choices' => range(0,10000)])
        ->getForm();
    return ['form' => $form->createView()];
}

view :

{% block content %}
    {{ form_row(form.list) }}
{% endblock %}

This takes 570ms with sf 2.5 and 2500ms with sf 2.6 on dev env.

it s because of #10887
sf 2.6 add a new feature, logging unknow translation. So for a 10000 string loop i had 10000 warning in the debug log.
I m not sure if the performance impact (2000ms) justify these 10000 logs since i dont know enough sf2 logging system.
So i just have to add

# app/config/config.yml
translator:
    logging:    false

i can live with that :)

@bdujon the issue has been solved by #13651 can you test with 2.7 ?

-       ->add('list', 'choice', ['choices' => range(0,10000)])
+       ->add('list', 'choice', ['choices' => range(0,10000), 'choice_translation_domain' => false])

@aitboudad i got 800ms with 'choice_translation_domain' => false. So i d say that fix it in a much better way than disabling globaly the translation log, thanks ! (now i want to use 2.7 with the fancy translation/twig debugbar :) ).
There is still 300 more ms than in 2.5 but i guess it s coming from other new features like the twig logger which add 10000 lines for showing the rendering of the form. 300ms for these 10000 lines seems fine so maybe there is really a performance problem with the translation warning logger ?

But there is another problem and maybe that has nothing to do with it but when i remove 'choice_translation_domain' to get the default behavior the debug bar goes into 404.

@bdujon nice, I'd say without translation warning logger I think it's difficult to detect those calls.

But there is another problem and maybe that has nothing to do with it but when i remove 'choice_translation_domain' to get the default behavior the debug bar goes into 404.

I'll check it :)

can I close this issue ?

Yes you can close it.

Thanks everyone for your help :)