Problem/Motivation
Currently the installer builds, compiles and dumps the container on every module install.
With 38 modules in standard.profile this means DrupalKernel::updateKernel takes around 28% of the install time on my local.
Proposed resolution
Progressively build the container, only adding the new functionality that comes from the module being installed, and only dump the container on terminate. This means running in a batch it will happen for each batch (not for each module) but running via drush - it should only happen once.
Profiling with blackfire.io using drush to install saves 8 seconds and 300kb of memory
Remaining tasks
Fix failing tests.
Reviews.
User interface changes
None.
API changes
None, but some parts of DrupalKernel are split into smaller protected methods.
Beta phase evaluation
Issue category | Bug because performance |
---|---|
Issue priority | Major because performance |
Prioritized changes | The main goal of this issue is performance |
Disruption | none expected |
Comment | File | Size | Author |
---|---|---|---|
#11 | install-kernel-dump.3.patch | 11.58 KB | larowlan |
#11 | interdiff.txt | 822 bytes | larowlan |
#4 | Screenshot 2014-12-22 13.16.57.png | 16.45 KB | larowlan |
#3 | install-kernel-dump.2.patch | 11.62 KB | larowlan |
#3 | interdiff.txt | 1.16 KB | larowlan |
Comments
Comment #2
larowlanHmm installs locally
Comment #3
larowlanwondering if this makes a difference, again note installs locally
Comment #4
larowlanpostponing the compile until the terminate event and thereby foregoing the clone saves another 5 seconds
Comment #5
larowlanComment #7
dawehnerAwesome work! This could also speed up tests quite a lot, right?
Wow, this really not seems related.
About how many percent do we talk about here?
Comment #8
Berdir"installs locally"
With an existing settings.php (with existing db connection) or not? I recently noticed that can make a world of a difference, make sure you try it with a freshly copied settings.php.
Comment #9
larowlan@berdir I had the same thought in the night, I think you're right, will try without an existing settings file
Comment #10
larowlanDawehner, not sure about tests
Comment #11
larowlandoh, this was the cause of the install issue - accidentally removed this hunk
Comment #12
larowlanWoohoo green, would be good to get someone else to profile and verify my figures
Comment #13
larowlan@dawehner - no improvement in testing speed, still 18 mins - #2367743: Remove usages of drupal_form_submit() and update documentation took same time (recent test on same bot)
Comment #14
joshtaylor CreditAttribution: joshtaylor commentedI don't see any difference with this patch, using Ubuntu 14.10, PHP 5.6.4.
I'm installing to a tmpfs sqlite database.
Without:
With:
MySQL with:
MySQL without:
Comment #15
moshe weitzman CreditAttribution: moshe weitzman commentedI ran
dr si -d -y
three times with the patch, and 3 times without. The patch made a minor difference for me (1 second). I'm determining elapsed time from the final log message reported by drush site-install. Maybe blackfire/xdebug is perturbing the measurements for larowlan?With patch: 33,32,31 (seconds)
Without patch: 33,33,34 (seconds)
Comment #16
moshe weitzman CreditAttribution: moshe weitzman commentedI did a couple more timings just for fun. These are without the patch
XHProf enabled: 40 seconds
XDEBUG enabled: 78 seconds (no client listening on xdebug port)
Comment #17
larowlanOK, no memory improvement either?
Comment #18
moshe weitzman CreditAttribution: moshe weitzman commentedSimilarly small.
Comment #19
Fabianx CreditAttribution: Fabianx commentedThis is wrong, because $class is never used.
The yaml_loader is only needed in the helper, so no need to have this here.
--
Oh, I get it, the InstallerKernel is re-using the loader, nvm. then, but should add a comment.
+1 in general to making those helper functions.
Isn't this over-optimization?
Maybe not, especially for tests.
Else the container would be compiled for the next request.
I personally would say its fine to never dump the container during installation.
It feels wrong to set this both on getContainerBuilder() and doCompile().
This _should_ already be the same.
This should save time. I cannot see why it does not, but maybe it is something else.
Comment #20
Fabianx CreditAttribution: Fabianx commentedWhile the idea is good, I think we will need to won't fix this:
- ContainerBuilder is before ->compile() not a real container and services will be missing from it, hence hook_install() and hook_modules_installed() would be a lie.
While that might work for core its a problem for contrib/ install profiles e.g..
Not helping core that much anyway as its only meaningful for drush as else the container needs to be build anyway via batching new requests and we just skip the ->compile() step.
In comparison to that turning off all caches and cache tags for installer duration gives a 50% performance increase.
(80s vs. 164s for a drush site-install)
So 8 seconds is not that much overall.
Comment #21
larowlansounds good