Skip to content

[DependencyInjection] made some perf improvements #10241

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.

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

Merged
merged 1 commit into from
Sep 26, 2014

Conversation

fabpot
Copy link
Member

@fabpot fabpot commented Feb 11, 2014

Q A
Bug fix? no
New feature? no
BC breaks? yes
Deprecations? no
Tests pass? yes
Fixed tickets n/a
License MIT
Doc PR n/a

This PR optimizes the creation of dumped containers drastically (thanks @jpauli for the hint).

The Container class generated by the PHP dumper does not include the getDefaultParameters() method anymore. It does not seem like a big deal to me as I fail to see a use case where someone would override this method.

@@ -105,6 +106,8 @@ public function dump(array $options = array())
'namespace' => '',
), $options);

$this->parameterArgName = 'p'.md5($options['class']);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it need to be a different name depending on the container class name ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it needs to if you simulate 2 clients for instance in the same process, each client/container must have its own parameters.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fabpot If the 2 clients have the same container class name, they will still share the same parameters. If they have different container class names, they will also have different static properties even if the name is not a hash

@henrikbjorn
Copy link
Contributor

Any benchmark which shows the "drastic" improvements?

@mvrhov
Copy link

mvrhov commented Mar 4, 2014

My quick test shows (removed container and pressed refresh a few times after it was rebuilt) about 300k lower memory usage (25,2M vs 25,5M) and about 10ms less load time in dev environment.. With this new commit.

@stof
Copy link
Member

stof commented Jun 16, 2014

@fabpot any news about this ?

@stof
Copy link
Member

stof commented Jul 9, 2014

@fabpot any news ?

@fabpot
Copy link
Member Author

fabpot commented Sep 24, 2014

Ready for me. ping @symfony/deciders

@Tobion
Copy link
Contributor

Tobion commented Sep 24, 2014

Looks ok to me. But I don't see the drastic improvment. Can somebody explain please why this improves performance?


$code = <<<EOF

private static \$parameters = $parameters;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the static property needed in case of non-frozen containers ? would it improve perf in this case ? The static array will need to be copied as soon as you manipulate parameters.

I know that this is kind of an edge case given that Symfony always freezes the container before dumping it (I'm not even sure there is valid use case for dumping a non-frozen container, given that parameters used in service definitions will always be inlined, so changing them in the ParameterBag will be useless for most of them)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, without a frozen container, the optimization won't work but it won't be worse than now, so as that should never happen, it does not really matters.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we prevent dumping a container which is not frozen in 3.0 given that the fact of dumping will freeze it partially ?

@stof
Copy link
Member

stof commented Sep 25, 2014

👍

@fabpot fabpot merged commit e1a3ef8 into symfony:master Sep 26, 2014
fabpot added a commit that referenced this pull request Sep 26, 2014
This PR was merged into the 2.6-dev branch.

Discussion
----------

[DependencyInjection] made some perf improvements

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | yes
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | n/a
| License       | MIT
| Doc PR        | n/a

This PR optimizes the creation of dumped containers drastically (thanks @jpauli for the hint).

The Container class generated by the PHP dumper does not include the `getDefaultParameters()` method anymore. It does not seem like a big deal to me as I fail to see a use case where someone would override this method.

Commits
-------

e1a3ef8 [DependencyInjection] made some perf improvements
@fabpot fabpot deleted the container-optim branch September 26, 2014 06:44
nicolas-grekas added a commit to nicolas-grekas/symfony that referenced this pull request Dec 3, 2014
…ovements (fabpot)"

This reverts commit 181e460, reversing
changes made to ff17493.
fabpot added a commit that referenced this pull request Dec 3, 2014
This PR was merged into the 2.6 branch.

Discussion
----------

[DependencyInjection] fix PhpDumper

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #12815
| License       | MIT
| Doc PR        | none

Commits
-------

7887a46 [DependencyInjection] keep some of the reverted perf optim
2f0b355 Revert "minor #10241 [DependencyInjection] made some perf improvements (fabpot)"
fabpot added a commit that referenced this pull request Dec 3, 2014
* 2.6:
  [DependencyInjection] keep some of the reverted perf optim
  Revert "minor #10241 [DependencyInjection] made some perf improvements (fabpot)"
  Remove deprecated class
fabpot added a commit that referenced this pull request Dec 3, 2014
* 2.7:
  [DependencyInjection] keep some of the reverted perf optim
  Revert "minor #10241 [DependencyInjection] made some perf improvements (fabpot)"
  Remove deprecated class
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants