[Meta] Make drupal install and run within reasonable php memory limits so we can reset the memory requirements to lower levels

decide what our goal min php memory is without APC
decide what our goal min php memory is with APC

Can we make this 'Not worse than Drupal 7 with views module installed'?

This might need splitting into sub-issues but we also have 2-3 places to compare memory requirements:

1. Installer
2. Full page render with cold caches
3. Full page render with warm caches

IMO, this is a non-critical task. I would not hold up release on it.

Changes to fix memory issues might require API changes, so we should at least have some understanding of what's required. It doesn't mean every single memory patch needs to be in, but that's not what the critical task is. From experience, trying to fix some really, really bad memory issues in 7.x took a lot of effort and time since I started that work about two weeks before 7.0.

Additionally out of memory errors on cache clear or module install are critical bugs and could leave a site in an unrecoverable state. There needs to be a decent understanding of what the memory requirements actually are, and they need to be at a reasonable state for a small site before the release is actually releasable.

Did someone identified why Drupal needs so much memory on the installer? I remember that there was a bug in doctrine annotations which we fixed, but there might be more out there.

Let's mark it as needs profiling to actually figure out where all that memory is used.

I tried to do some profiling, but xhprof memory report is drunk, I'm getting numbers between -3GB and +5GB but the total is 176MB for an install profile with 98 modules, installed with drush.

Any ideas on getting better results? Is uprofiler better at that?

As far as execution time goes, I'm seeing a lot of time spent doing DB queries (110k queries, 25s, 15% of the whole time), A huge amount of that is Drupal\Core\Cache\ChainedFastBackend::markAsOutdated() (24k calls, 17s.

I'm spending 50s in Drupal\Core\Plugin\DefaultPluginManager::findDefinitions(), 70% of that is config schema, the remaining 30% are 50/50 in annotation parsing and derivates.

Yaml parsing is 8k calls, 40s, 22% of the time, almost exclusively coming from config, and most of that is is typed config, as already mentioned above from the other perspective.

Someone mentioned that @alexpott has an issue to add an APC wrapper on top of Yaml parsing, that's might help, but I'm wondering if we should make the typed config parsing more intelligent, and do something better than re-parsing everything when adding a module. I don't know..

This much memory usage is a bug.

How come chained backend is used during the installer at all? Shouldn't that be null or memory?

Also while I haven't used it for a long time, xdebug can provide memory traces: http://derickrethans.nl/xdebug-and-tracing-memory-usage.html

I've some data to share. I've xhprofiled a standard english D8-beta3 installation on Ubuntu 14.04 with Apache 2.4 and PHP 5.5.

The peak memory usage has been 27,237,024 bytes. PDOStatement::execute is the function consuming the most memory (22.8%), triggered by Drupal\Core\Database\Driver\mysql\Insert::execute, which looks reasonable to me.

PHP 5.5 comes with Zend OPcache (not APC). In order to test PHP 5.4 (with/without APC) I would have to setup another Ubuntu 12.04 box and upgrade PHP 5.3 to 5.4.

Time permitting, I will also test a spanish installation.

Alright! Now the same standard installation, but on Ubuntu Precise (64bits).

The stack consisting of Apache 2.2, PHP upgraded to 5.4.35, APC 3.1.13.

Peak memory usage: 55,969,872 bytes (doubling the previous installation peak on Ubuntu 14.04).

The top memory consumer function in this case is apc_fetch() with a peak of 8,546,880 bytes, and there is also the strtr() function in the 3rd place, consuming 5,659,688 bytes. The DB calls (PDOStatement::execute) rank 2nd, peaking at 6,186,488 bytes of memory consumed.

Drupal\Core\Config\TypedConfigManager::replaceName uses strtr() heavily, peaking 1.5M. Similar case with Symfony\Component\DependencyInjection\Container::get, peaking at 2M, of which 35.7% is due to strtr().

Same standard installation, but without APC (Apache 2.2, PHP upgraded to 5.4.35,):
83,102,880 bytes (ouch!)

strtr() is now the top memory consumer.

After a quick dive into the source code of those callers of strtr(), one concludes that calling strtr() with 3 parameters is OK, but calling it with 2 params (the string and an array) is a memory hog.

I've tried a simple patch to class
Symfony\Component\DependencyInjection\Container
and I was able to take the aforementioned peak of 83,102,880 bytes down to 74,627,568 bytes.

The patch responsible for saving that 10% consists of a simple shortcut function which transforms the 2-params call to a 3-params call.

function _strtr($str, $replace_pairs) {
    foreach($replace_pairs as $target => $replacement) {
        $str = str_replace($target, $replacement, $str);
    }

    return $str;
}

I believe we should be able to save around 20% in PHP 5.4 by applying this remedy to a larger code population.

Tried the same installation in PHP 5.4 but with APC enabled, with the patch applied to 2 classes.

This time the peak remained almost the same (at 55,376,936 bytes) due to apc_fetch() (being called by Drupal\Core\Cache\ChainedFastBackend::getMultiple). apc_fetch() peaked at 9,337,496 bytes.

However, strtr() memory peak is now down to 577,912 bytes from 5,659,688.

Conclusions:

Say we have a) minimum and b) recommended requirements for a vanilla Drupal installation,
a) PHP 5.4 => minimum 64M for PHP (with or without APC)
b) PHP 5.5 => minimum 32M for PHP

For b) we're already there, and for a) not there yet, but doable.

I've written a patch that wraps all 2-param calls to strtr().

With the patch applied:

• Using PHP 5.4 with APC, running the same standard installation process, memory usage peaked at 55,858,848 bytes.
• Using PHP 5.4 without APC, running the same standard installation process, memory usage peaked at 83,167,240 bytes.
• Using PHP 5.5, running the same standard installation process, memory usage peaked at 27,239,812 bytes.

The peak of strtr() did go down, and it does no longer surface in the report of exclusive memory peaks.

Although the memory consumption is decreased, it seems there are other "critical paths" where the peaks are being reached.

A deeper analysis is needed, but:

1. PDOStatement::execute is peaking at 6M in every PHP version.
2. serialize() is peaking at 6M in PHP 5.4, and only 2M in PHP 5.5.
3. Also, file_get_contents() is in the top 5, peaking at 1.7M in PHP 5.5 but much higher in PHP 5.4.

In xhProf I can browse caller/calling function/methods with memory consumed, etc., but I don't have a detailed trace of each call. For example, I can clearly see a spike of memory usage near the end of the installation process, but I cannot tell more than that.

I'm attaching the patch for reference, and I will be looking forward to more feedback/contributions.

+++ b/core/includes/utility.inc
@@ -48,9 +48,22 @@
+  foreach ($replace_pairs as $target => $replacement) {
+    $str = str_replace($target, $replacement, $str);
+  }

What's the memory impact if we change this from a foreach to using array parameters to str_replace() (e.g., $str = str_replace(array_keys($replace_pairs), array_values($replace_pairs), $str);)?

serialize() is peaking at 6M in PHP 5.4, and only 2M in PHP 5.5.

What about unserialize()? I ask, because #15 mentions apc_fetch(), and an apc_fetch() does an internal equivalent of unserialize, so if we have large data chunks contributing to that, then that should be showing up as memory used by unserialize() on a non-APC environment.

user_modules_installed is a major consumer - being run 38 times in the standard install - each with a $role->save().

/**
 * Implements hook_modules_installed().
 */
function user_modules_installed($modules) {
  // Assign all available permissions to the administrator role.
  $rid = \Drupal::config('user.settings')->get('admin_role');
  if ($rid) {
    // Some permissions call the url generator, so ensure that the routes are
    // up to date.
    \Drupal::service('router.builder_indicator')->setRebuildNeeded();
    /** @var \Drupal\user\PermissionHandlerInterface $permission_handler */
    $permission_handler = \Drupal::service('user.permissions');
    $permissions = $permission_handler->getPermissions();
    if (!empty($permissions)) {
      user_role_grant_permissions($rid, array_keys($permissions));
    }
  }
}

If we defer this to only run once at the very end of the install process, rather than 38 times locally I saved 5s and ~4Mb

See #2395113: user_modules_installed calls $role->save() and PermissionsHandlerInterface::getPermissions 38x in standard install

Also noticed we're calling Drupal\Core\Config\FileStorage::read() 1772 times, but we only have 1244 yml files in all of core, so added #2395143: YAML parsing is very slow, cache it with FileCache

Child issue #2395113: user_modules_installed calls $role->save() and PermissionsHandlerInterface::getPermissions 38x in standard install is green, if anyone feels like reviewing

Added #2396341: During install ConfigSchemaDiscovery runs 43x saves 11s on my local install

Another child issue #2396939: Make the InstallKernel progressively build the container instead of building, compiling and dumping from scratch on every module install (38x) saves 300kb and 8s on my local

With #2395143: YAML parsing is very slow, cache it with FileCache applied, the biggest issues that I can identify at the moment are. Note that I have been looking at this in a custom install profile that installs ~110 modules. Memory usage is based on blackfire.io's interpretation, the uprofiler output gives me completely bogus data. I also installed with drush, web might take longer but I'd expect a smaller peak memory usage.

Uprofiler status:
- 200s
- 180 MB (Remember, drush si with 110 modules, all in a single request, so not that bad IMHO)
- 200 MB peak usage (not exactly sure what that means in this case..)

Again, as a reminder, the install with the same setup without uprofiler and xdebug takes only 122s. So anything that is slow because of a lot method calls is at least partially due to profiling.

• In my install, I'm seeing the insane amount of 127k database queries (15% with mysql optimized for speed). A big part of it is createTable(), with 250 calls (lots of fields), but by far the biggest problem I can find is that we are doing 40k Merge queries (1 select + 1 update). Those are caused by 34k cache backend set(), 26k of those are markAsOutdated(). There are ways to optimize that (we're doing one for every cache tag invalidation), but the easiest would be to not use the fast cache backend during install (a check for the maintenance mode constant maybe?). This is also the cause of the biggest memory usage.
• Does anyone know why we do a manual, blocking cron call at the end of the installer? That is quite costly (~5s) especially with update.module enabled and doesn't seem to be that useful? poormans cron is enabled by default, so the first request to the site should do that anyway, in a less blocking way
• I can also confirm the large memory usage of strtr(), 26MB in my case.
• AnalyzeServiceReferencesPass is ~10% of the install time. It is executed multiple times within a RepeatedPass (5x as many as a normal pass), I'm seeing 600k calls to processArguments(). This might be a worthy thing to look at for micro-optimization or finding a way to avoid calling it so often. That said, 600k calls also means a huge amount of of profiling overhead.

So after #2395143: YAML parsing is very slow, cache it with FileCache, the most important thing to optimize IMHO is the fast chained cache backend. Just disabling that manually saves ~54k queries in my case and 8% of the wall time, almost no memory though, which makes sense.

We also need to compare with web installer and standard profile. I'm fairly sure that using the memory cache backend would result in the best performance for drush install, not sure about web (would not be that surprised if would be faster as well, though).

Opened #2422657: Skip fast chained cache backend during installer.

Does anyone know why we do a manual, blocking cron call at the end of the installer? That is quite costly (~5s) especially with update.module enabled and doesn't seem to be that useful? poormans cron is enabled by default, so the first request to the site should do that anyway, in a less blocking way

I can't find the issue that added this, but I remember it. Opened #2289201: [Meta] Make drupal install and run within reasonable php memory limits so we can reset the memory requirements to lower levels to remove it with some background.

Meant to link to #2422681: Remove the automatic cron run from the installer.

This is a just for information:

I don't think Drupal is to blame too much for the installation via drush.

A simple drush status uses 24 MB, while a page cache hit uses 2 MB.

A normal front page non-cache hit has 18 MB.

So around at least 6-8 MB need to be added as requirements when dealing with drush and Drupal.

Tentatively tagging for the Performance sprint at Dev Days coming up.

Tagging, as there's no clear "next steps" here.

I'm not really sure what more we can do here.

On PHP 5.6, my custom install profile that apparently installs 116 modules:

Congratulations, you installed Newsportal 8! [76.21 sec, 96.35 MB]

Standard:

Congratulations, you installed Drupal! [17.14 sec, 35.71 MB]

Minimal:

Command dispatch complete [4.68 sec, 25.36 MB]

The same with PHP7

Congratulations, you installed Newsportal 8! [38.99 sec, 62.28 MB]
Congratulations, you installed Drupal! [8.1 sec, 22.78 MB]
Congratulations, you installed Drupal! [2.75 sec, 18.95 MB] 

So on PHP 5.6 (and I think also 5.5), it's looking pretty good and awesome on PHP 7 ;)

Can someone test standard/minimal on 5.4/5.5? Sounds like there might be that strtr problem on 5.4 still, but most calls are in symfony's Container.php, so we'd need a pull request there to do something about it.

Note: According to xhprof, 50% of the install time for my install profile is spent in DrupalKernel::updateModules() aka rebuilding the container, but I really don't know if we can do something about that.

So @larowlan raised the point that D7 standard did not include Views. :P

Compiling a list of functions that could be moved into includes to reduce code loaded at run time

node.module

• node_page_title - note might even be dead code (docblock references node_menu!)
• node_get_recent - not needed on every request
• node_access_view_all_nodes - not needed on every request
• node_access_needs_rebuild - not needed on every request
• node_access_rebuild - not needed on every request
• _node_access_rebuild_batch_operation - not needed on every request
• _node_access_rebuild_batch_finished - not needed on every request
• node_reindex_node_search - not needed on every request
• node_title_list - not needed on every request
• node_mark - not needed on every request
• node_add_body_field - not needed on every request

That's just one module - a good novice task would be to do the same analysis for other modules - only hooks and really commonly used api functions need be in the .module.
Clean-up and identification is a great novice sprint task.
Thoughts?

block.module

• _block_rehash
• block_theme_initialize
• block_rebuild

ckeditor.module

• _ckeditor_theme_css
• ckeditor_rebuild

color.module

Most of this module isn't needed on *every* request - candidates

• color_get_info
• color_get_palette
• color_scheme_form
• color_scheme_form_validate
• color_scheme_form_submit
• color_palette_color_value
• color_valid_hexadecimal_string
• _color_rewrite_stylesheet
• _color_save_stylesheet
• _color_render_images
• _color_shift
• _color_gd
• _color_unpack
• _color_pack
• _color_hsl2rgb
• _color_hue2rgb
• _color_rgb2hsl

comment.module

candidates

• comment_view?
• comment_view_multiple?
• _comment_entity_uses_integer_id
• comment_preview?

contact.module

• contact_user_profile_form_submit
• contact_form_user_admin_settings_submit

menu_link_content.module

• _menu_link_content_update_path_alias

block_content.module

• block_content_add_body_field

editor.module

A lot of this relates to admin functions, so could be in an admin.inc, the form_alter could load the include and call to another function to do the guts of the altering, allowing the submit/validate to live there too

• editor_form_filter_admin_format_editor_configure
• perhaps guts of editor_form_filter_format_form_alter could be moved to an include as required and then the next four too
• editor_form_filter_admin_format_editor_configure
• editor_form_filter_admin_form_ajax
• editor_form_filter_admin_format_validate
• editor_form_filter_admin_format_submit
• editor_filter_xss
• _editor_record_file_usage
• _editor_delete_file_usage
• _editor_get_file_uuids_by_field
• _editor_get_formatted_text_fields
• _editor_parse_file_uuids

entity_reference.module

These could be loaded on demand I think

• _entity_reference_field_field_settings_ajax_process
• _entity_reference_field_field_settings_ajax_process_element
• _entity_reference_form_process_merge_parent
• _entity_reference_element_validate_filter
• entity_reference_settings_ajax
• entity_reference_settings_ajax_submit

Still to review

• - menu_ui
• - options
• - path
• - page_cache
• - taxonomy
• - dblog
• - search
• - shortcut
• - toolbar
• - field_ui
• - file
• - rdf
• - views
• - views_ui
• - tour

@larowlan
Can you please summarize that in a new issue? "Reduce loaded functions", I think this will need measurement and what not. This is a meta issue.

@larowlan as I understand these findings, they are essentially pointing at the remaining work to be done to fully convert Drupal to OOP. While desirable, the API changes required would not be possible for 8.0.

@dawehner yep

@jhedstrom no, I'm saying these util functions are in .module files that are loaded on every request when said module is enabled - and as these are all in standard, impact its installation - the functions I've listed aren't hooks or involved in the critical path, so are good candidates for moving to .inc files and loading on demand.

if anyone else doing critical office hours today in NA/Europe has time - could they create the 'reduce loaded functions' issue as a child of this? I'm unlikely to have time until tomorrow now.

views_ui.module
Possible candidates for moving to an include file in views_ui.module:

• views_ui_view_preview_section_handler_links
• views_ui_view_preview_section_display_category_links
• views_ui_view_preview_section_rows_links
• views_ui_truncate

rdf.module
Possible candidates for moving to an include file in rdf.module:

• rdf_get_mapping
• rdf_get_namespaces
• rdf_rdfa_attributes

options.module
Possible candidates for moving to an include file in options.module:

• _options_values_in_use

So, added a shutdown function to install.php to print out the peak memory usage and installed through the UI

English, PHP 5.6, no xdebug/xhprof (this is important, xdebug pretty much doubles memory usage)

10.04
10
7.98
16.13
9.6
15.92
15.77
17.62
16.41
17.24
17.09
17.56
20.34
17.98
18
17.92
19.32
15.76
9.11
34.08
10.79
25.08

German :

9.99
7.99
11.04
8.96
16.1
10.63
16.91
16.8
18.65
17.43
18.24
18.91
18.53
19.03
18.26
22.06
19.5
20.94
22.36
18.55
19.98
18.83
23.43
19.08
23.22
24.77
23.69
10.81
37.24
14.21
12.05
12.29
13.43
14.56
15.44
15.35
13.78
10.7

The biggest number there is the full cache rebuild before the install configure form. We could possibly get rid of that now, but that's something that needs to be considered as well.

I also tried with the two additional file cache issues (#2447803: Use FileCache for caching discovered annotations and #2473179: Use FileCache for config storage), that helps a bit. A bit hard to compare, because what it also is is quite a bit faster, so fewer batch requests. (18 requests until the big cache clear instead of 20, if I counted right)

10.07
8.02
16.28
9.65
16.04
16.24
16.81
15.42
15.57
16.3
15.77
19.71
16.74
16.57
15.85
17.97
9.12
33.46
10.79

Also, as discussed above. The 32MB thing for D7 is quite a joke, enable a handful of modules like views and you're very, very fast far beyond that. We have sites where 256MB is not enough for a drush cc all. My recommendation would be to *not* go below 64MB, what do we gain if people can install with less and then their site breaks when they start adding some content/config/modules?

It would be good to get a baseline of what D7 + Views + Entity API + etc. needs in terms of memory before going too much more nuts on this. We need to have a target to shoot for here.

Given this:

My recommendation would be to *not* go below 64MB, what do we gain if people can install with less and then their site breaks when they start adding some content/config/modules?

While it's not the same, here are the memory requirements of some of the top distributions, to give some idea of what a "full" Drupal site needs in D7:

- Commerce Kickstart: 128M http://cgit.drupalcode.org/commerce_kickstart/tree/commerce_kickstart.in...
- Open Atrium: 256M http://cgit.drupalcode.org/openatrium/tree/README.txt
- Commons: 128M http://cgit.drupalcode.org/commons/tree/commons.info#n123
- Panopoly: 196M https://www.drupal.org/node/1717734

So the lowest in that list is 128M, which is double the minimum in D8 (64M).

While the issues cross-referenced in #52 look worthy of fixing, I'm left wondering if this is actually critical, or even major? Is it instead just "Yes, Drupal 8 ships with more handy stuff available out of the box. You're welcome." ;)

While the issues cross-referenced in #52 look worthy of fixing, I'm left wondering if this is actually critical, or even major? Is it instead just "Yes, Drupal 8 ships with more handy stuff available out of the box. You're welcome." ;)

I think this is exactly the right question.

Personally I think 64 MB compared to 128 MB for those very popular distributions seems reasonable?

Well, the point is that we can run Drupal with 32 MB out of the box (and there is a lot of things), but the installation is still maxing out.

However we are way way way closer than ever before to that goal as berdirs benchmarks show.

If you compare with my findings in:

#2294569-7: Determine cause of high memory consumption and #2294569-8: Determine cause of high memory consumption

Especially thanks to the Config::save issue().

Updated the issue summary so that people can actually easier find your findings

This is sounding more encouraging indeed recently.

I'm not sure about moving functions out of .module files, that tends to be quite a small trade-off with an opcode cache and has to be manually reviewed for every module.

However... one thing in Drupal 7 that does take a lot of memory is loading .install files, and that hasn't changed much in 8.0.x.

admin/* pages can end up calling hook_requirements()

hook_requirements() lives in .install files

.install files contain both schema and potentially dozens of hook_update_N() functions.

And since they aren't needed otherwise, they're often an opcode cache miss which means higher memory usage anyway.

We don't need to know updates when installing a module, and we don't need updates, install or schema hooks when checking requirements.

Would have to be an API change though since we absolutely don't want to look in both files.

Created a subissue for that: #2486163: Split up .install files for schema, requirements and hook_update_N

I think this is the biggest problem in Drupal and the one that make me think twice before using it.
webchick post shows why this is critical. Most shared hosting companies sell 32MB ou 64MB hostings.
Having a distribution using 128MB or more is not acceptable while other CMS use less resources to do the same thing.

I was really expecting Drupal 8 to use less memory than Drupal 7. Drupal 7 already uses too much memory.
I think 32MB is acceptable for a Drupal site and 64MB for a distribuition.
I think this should be or should have been a main "feature" in Drupal 8. "Look, we use less resources!"

(OT: btw.... another problem is how to post comments in issues... this is not intuitive)

Most shared hosting companies sell 32MB ou 64MB hostings.

First, I'm sorry for barging in in an issue thread which I have not contributed to previously. Is this really true though that most hosts offers so little RAM? Here are a few examples:

DigitalOcean offers minimum 512 MB which is also shared with the OS (e.g. Ubuntu 14.04), which should leave about 200 MB to the application (Drupal) to use.

Go Daddy offers 256 MB minimum on shared hosting.

Linode starts at 1 GB, but like DigitalOcean a portion of that will be used by the operating system.

Bluehost limits to 128 MB.

Hostgator limits to 256MB.

SiteGround limits to 96 MB which is the lowest offered memory I can find anywhere.

Media Temple limits to 99 MB.

@NiklasBr
Thank you a lot for that research! Its a clear sign that many of us are living in our own happy world of using proper servers / "the cloud".
It totally makes sense, see moore's law, that also hosting companies can run with it.

Did a couple of research for german hosters and wordpress, just to see, how things are in europe.
These are always the cheapest options available.

• Hosteurope: 128 Mb
• strato104 MB for recent PHP versions
• One.com 128 MB
• DomainfactoryStarting from 100MB but you seem to be able to access the .htaccess file
• 1&190MB
• Interesting sidefact: https://github.com/WordPress/WordPress/blame/c2260dc85b279ac202a2fc4a6b4... ... Wordpress tries to change the PHP memory to at least 40MB, which was the constant last time changed in 2012

No question, Drupal should run with not incredible high memory, especially because memory is also often just a sign for a unperformant code,
but it seems to be a thing you have to care less about these days.

Let's have a look at some of the runtime memory usage:

• settings.local.php, /node as admin, no content, with fresh drush cr: peak memory usage 28 MB
• settings.local.php /node with 10 nodes with fresh drush cr, without render cache: 33MB
• /node with 10 nodes with fresh drush cr, with default settings.php: 36MB
• /node with 100 nodes with fresh drush cr, with default settings.php: 46MB

More Shared hostings.

memory_limit:
OVH: from 128Mb to 512Mb.
Arvixe: 512MB
GreenGeeks: 512MB

64Mb seems acceptable, all shared hostings we have found has an upper limit.

Two shared hosting providers I use in UK:

Valuehost.co.uk - php 5.5.5, 128Mb limit
Namesco.co.uk - choice of php 5.5 or 5.6 with 128Mb limit

Dreamhost: 90 MB
Gandi: 128 MB

Discussed this with @dawehner, @tim.plunkett, @xjm, @alexpott, @webchick and @Fabianx. We all think that a limit of 64 MB is acceptable, especially given the actual limits on actual hosts. We should keep memory usage under control, and making memory improvements is great, but not a critical bug that we should block release on.

Fabianx also thinks we should aim to get the Standard install profile to work under 40 MB, but keep the limit at 64 MB. That 64 MB limit allows users to still install a bunch of modules and have that work. For just core though, we should aim for something lower, precisely to allow contrib modules to be installed without going beyond the memory limit.

We think it's up to catch to actually demote.

@Fabianx further recommended that we choose an "internal" target for Standard profile that's lower than 64M in order to catch any memory performance regressions. @Wim and he and I talked, and based on @Berdir's benchmarking, we set this target at 40M.

Documenting this, and removing the @todo pointing to this issue.

RTBC, this looks great to me!

Leaving for catch to decide. :)

+1, fully agreed. A memory limit that just allows to install but then not actually do anything is kinda pointless ;)

In a separate issue, we should possibly look at the memory usage of certain pages. Especially the permission page is really bad. I have a site with 13 roles, which isn't *that* much, and 256MB is not enough to display the full permission page anymore.

I think we can call 64mb 'reasonable' given Drupal 8 has more modules than Drupal 7 in the standard profile - and we know Drupal 7 sites in reality have far higher memory requirements than 32mb.

While this issue is 'install and run' in the title, it's mainly been about the installer, and we've got that to a much better point than it previously was, so agreed on setting things to 64mb officially and closing this meta.

However I had a quick look at the permissions page with xhprof and opened #2488538: Add SafeMarkup::remove() to free memory from marked strings when they're printed as a new critical issue since that's going to go over 64mb with just five custom roles and no contrib (well found Berdir). I think any other pages that are easily going over that limit, we should treat as critical in their own right - but we can just track those under #1744302: [meta] Resolve known performance regressions in Drupal 8.

Yay! Thanks catch!

Also adding a few people to the d.o credit list since they did way more work than me on this issue. :P