8000 [DI] Bad performance for dump/compile compared to 3.2.x · Issue #24201 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

[DI] Bad performance for dump/compile compared to 3.2.x #24201

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
TiMESPLiNTER opened this issue Sep 14, 2017 · 17 comments
Closed

[DI] Bad performance for dump/compile compared to 3.2.x #24201

TiMESPLiNTER opened this issue Sep 14, 2017 · 17 comments
Labels
DependencyInjection

Comments

@TiMESPLiNTER
Copy link
TiMESPLiNTER commented Sep 14, 2017 •
edited
Loading
Q A
Bug report? yes
Feature request? no
BC Break report? no
RFC? no
Symfony version 3.3.9

I upgraded from the latest 3.2.x version to 3.3.6 and have massive performance issues (during PHPUnit tests) which I could track down to the container component. I did some benchmarks for both 3.2.x and 3.3.6 and compared them (see blackfire screenshot - removed as comparision is no accurate yet).

I don't use autowiring at all and disabled it in config to make sure bad performance is not caused by this feature.

If I can provide any additional information to solve this "bug" just let me know.

app/config.yml

services:
    _defaults:
        autowire: false
        autoconfigure: false

Benchmarks

3.2.x 3.3.9 Xdebug active
Tests without coverage ~16min ~23min no
Tests with coverage ~30min >1.5h yes
@NicoHaase
Copy link
Contributor

Try updating to 3.3.9, there have been some performance tweaks.

@chalasr
Copy link
Member
chalasr commented Sep 14, 2017

See also #23601

@TiMESPLiNTER
Copy link
Author
TiMESPLiNTER commented Sep 14, 2017 •
edited
Loading

@NicoHaase Okay found out that symfony dropped support for PHP 7.0 in a bugfix release. That's quite tricky to spot. However after installing 3.3.9 the situation is still the same. So I update my issue with the newest version of symfony.

@stof
Copy link
Member
stof commented Sep 14, 2017

@TiMESPLiNTER we haven't dropped support for PHP 7.0. We dropped support for 7.0.0 to 7.0.7 because they have bugs affecting Symfony too badly (and without workaround). PHP 7.0 is currently at version 7.0.23. Running 7.0.0 or 7.0.7 does not make sense (and these versions have security issues)

@TiMESPLiNTER
Copy link
Author
TiMESPLiNTER commented Sep 14, 2017 •
edited
Loading

@stof okay you're right. 😃 But still the performance issues persist.

@sstok
Copy link
Contributor
sstok commented Sep 14, 2017

Try removing the ProxyManager and see if this improves performance, most calls seem to relate to from that library.

@nicolas-grekas
Copy link
Member

There can be several reasons to this:

  • compiling the container can be slower - we do more recursive processing since 3.3
  • maybe your new configuration declares more services so there are more to process
  • in both cases, why isn't there a predumped container that tests could reuse instead? (do we have that?)

That'd be interesting to debug :)

@TiMESPLiNTER
Copy link
Author

@nicolas-grekas a predumped container reusable for all tests (I have >5000) would be amazing. But I don't think it's possible, right?

Well I still have the same amount of services declared as with 3.2.x or do you mean SF 3.3 declares more services than 3.2?

@sstok but if I remove it the performance would be even worse if I instatiate all services all the time. I don't think I would be able to tell you whether tests are slower or faster than before. Or what were your thoughts behind that proposal?

@nicolas-grekas
Copy link
Member

same amount of services declared as with 3.2

I was referring to autowire: false, which is the default already so couldn't make any difference. But maybe you added some prototype rule to load all classes in src/ as services, since that's a new default with 3.3?

SF 3.3 itself does declare some things differently, and may take more time to process those, but you're the first to report this amount of increase, so I'm not sure that's the core reason.

Can you please share a link to the 3.3 profile itself?

@linaori
Copy link
Contributor
linaori commented Sep 14, 2017

I ran into some issues with 3.3 and phpdbg (for coverage), as it took up too much memory during the container compilation. Solved this issue by using composer scripts to first build the test container and then have my scripts use that.

@nicolas-grekas
Copy link
Member

Blackfire profiles welcomed, either publicly or privately (e.g. on SF-dev Slack.)

@TiMESPLiNTER
Copy link
Author

@nicolas-grekas

But maybe you added some prototype rule to load all classes in src/ as services, since that's a new default with 3.3?

How can I disable that feature?

@iltar That sounds very interesting. How have you done that? Because that would help speeding up the test suite anyway. 👍

@nicolas-grekas
Copy link
Member

@TiMESPLiNTER same as for autowiring: it's not enabled, unless you did it. So only you know the answer.

@TiMESPLiNTER
Copy link
Author
TiMESPLiNTER commented Sep 15, 2017 •
edited
Loading

@nicolas-grekas so it's definitely not enabled then. 😉

@linaori
Copy link
Contributor
linaori commented Sep 15, 2017

@TiMESPLiNTER basically what I've done (to not go off-topic too much, can discuss this on slack), is add this to composer:

"scripts": {
    "build:test-env": "bin/console cache:clear --env=test --no-warmup; bin/console cache:warmup --env=test"
},

Additionally I've added this in my test cases that require the container/app:

public static function getKernelClass(): string
{
    return AppKernel::class;
}

Then everything that runs my tests (even if in matrix on same user/machine), uses that test env when I run composer build:test-env. It might not be the best solution, but it does speed things up tremendously. I do this because I don't have a build server available.

@TiMESPLiNTER
Copy link
Author

Okay I realized I compared a non-cached container test run against a cached one which explains the difference between the two test runs I did. I'm working on a new profiling with cache. Sorry for the confusion.

@TiMESPLiNTER
Copy link
Author
TiMESPLiNTER commented Sep 25, 2017 •
edited
Loading

We found the issue. We use the jms/serializer-bundle dependency and have a factory to instanciate a new serializer:

class SerializerFactory
{
    public function getSerializer()
    {
        return SerializerBuilder::create()->build();
    }
}

which we then use in the services.yml to create services using the factory. Since SF 3.3 if we use the SerializerBuilder class of the above mentioned package we have slow tests. Creating the JMS serializer instance without the SerializerBuilder but with the plain constructor of the Serializer object resolves speed issues.

I have no idea why the SerializerBuilder class slows down tests since SF 3.3 but the more this class is used in tests the slower they get.

Thanks for your help. 😃 It was hard to find that issue but I guess it doesn't really have something todo wth SF.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
DependencyInjection
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@nicolas-grekas @stof @TiMESPLiNTER @sstok @NicoHaase @linaori @chalasr
0