events.action: opened
events.author: zayders
events.masked_author: username_0
events.text: My `composer.json`:
  
  ```json
  {
      "name": "symfony/framework-standard-edition",
      "license": "MIT",
      "type": "project",
      "description": "The \"Symfony Standard Edition\" distribution",
      "autoload": {
          "psr-4": { "": "src/" },
          "classmap": [ "app/AppKernel.php", "app/AppCache.php" ]
      },
      "autoload-dev": {
          "psr-4": { "Tests\\": "tests/" }
      },
      "require": {
          "php": ">=5.5.12",
          "symfony/symfony": "3.4.*",
          "doctrine/orm": "^2.5",
          "doctrine/doctrine-bundle": "^1.6",
          "doctrine/doctrine-cache-bundle": "^1.2",
          "symfony/swiftmailer-bundle": "^2.3",
          "symfony/monolog-bundle": "^3.0",
          "symfony/polyfill-apcu": "^1.0",
          "sensio/distribution-bundle": "^5.0",
          "sensio/framework-extra-bundle": "^3.0.2",
          "incenteev/composer-parameter-handler": "^2.0",
          "twig/extensions": "~1.0",
          "doctrine/doctrine-fixtures-bundle": "~2.3",
          "symfony/assetic-bundle": "^2.7.1",
          "leafo/scssphp": "~0.6",
          "patchwork/jsqueeze": "~1.0",
          "coresphere/console-bundle": "dev-master",
          "friendsofsymfony/user-bundle": "dev-master",
          "egeloen/ckeditor-bundle": "^4.0",
          "jms/serializer": "^1.7",
          "vich/uploader-bundle": "^1.4",
          "liuggio/excelbundle": "^2.1",
          "spipu/html2pdf": "^5.0",
          "ob/highcharts-bundle": "^1.6",
          "ocramius/proxy-manager": "^1.0",
          "oneup/uploader-bundle": "^1.9"
      },
      "require-dev": {
          "sensio/generator-bundle": "^3.0",
          "symfony/phpunit-bridge": "^4.1"
      },
      "scripts": {
          "symfony-scripts": [
              "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
              "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
              "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
              "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
              "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile",
              "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::prepareDeploymentTarget"
          ],
          "post-install-cmd": [
              "@symfony-scripts"
          ],
          "post-update-cmd": [
              "@symfony-scripts"
          ]
      },
      "config": {
          "platform": {
              "php": "5.5.12"
          }
      },
      "extra": {
          "symfony-app-dir": "app",
          "symfony-bin-dir": "bin",
          "symfony-var-dir": "var",
          "symfony-web-dir": "web",
          "symfony-tests-dir": "tests",
          "symfony-assets-install": "relative",
          "incenteev-parameters": {
              "file": "app/config/parameters.yml"
          },
          "branch-alias": {
              "dev-master": "3.2-dev"
          }
      }
  }
  
  ```
  
  Output of `composer diagnose`:
  
  ```
  Checking composer.json: WARNING
  Defining autoload.psr-4 with an empty namespace prefix is a bad idea for performance
  require.coresphere/console-bundle : unbound version constraints (dev-master) should be avoided
  require.friendsofsymfony/user-bundle : unbound version constraints (dev-master) should be avoided
  Checking platform settings: OK
  Checking git settings: OK
  Checking http connectivity to packagist: OK
  Checking https connectivity to packagist: OK
  Checking github.com rate limit: OK
  Checking disk free space: OK
  Checking pubkeys: 
  Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
  Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
  OK
  Checking composer version: OK
  Composer version: 1.7.3
  PHP version: 5.5.12 - Package overridden via config.platform (same as actual)
  PHP binary path: D:\wamp\bin\php\php5.5.12\php.exe
  
  ```
  
  When I run this command:
  
  ```
  php ..composer.phar update
  ```
  
  I get the following output:
  
  ```
  Fatal error: Out of memory (allocated 1520435200) (tried to allocate 268435456 b
  ytes) in phar://D:/wamp/www/composer.phar/src/Composer/DependencyResolver/Solver
  .php on line 220
  ```
  
  And I expected this to happen:
  
  Update all dependencies
  
  I try several solution but nothing is working :
  
  - My php.ini is already modify with memory_limit = -1
  
  - the command php -d memory_limit=-1 ../composer.phar update
  
  - The command php ../composer.phar install (work fine but after i have the same error when i run composer update)
  
  - Try composer self-update to get last version
  
  - Try to edit composer.bat to up the memory
  
  - I'm on php 5.5.12, i can't upgrade to php 7.X due to my restrictions. And i tried to upgrade to php 5.6 and it not solve the problem, always this error : "Out of memory"
  
  My computer has 4Gb RAM and about 2,4 available when i want to execute the command
events.title: Fatal Error : out of memory with Composer Update
events.type: issue
events.action: created
events.author: alcohol
events.masked_author: username_1
events.text: Your error indicates it is not hitting the imposed limit, but rather a physical limit. You are literally out of memory. There is not much we can do from our end about this. I would suggest you try to narrow your constraints as much as possible.
events.type: comment
events.action: created
events.author: myspulin
events.masked_author: username_2
events.text: Hi Guys, I have spent couple hours to solve memory issue during composer upate on my projects. I have the latest version of composer 1.7.3, run PHP 7.2, OS win7 x64, RAM 16GB and have no luck at all. On overy project it gives me out of memory. I have changed memory limit to unlimited, no luck, which is strange. I have checked the code inside composer.phar and find out this code:
  
  // Increase memory_limit if it is lower than 1.5GB
      if ($memoryLimit != -1 && $memoryInBytes($memoryLimit) < 1024 * 1024 * 1536) {
          @ini_set('memory_limit', '1536M');
      }
  
  So the memory limit is set to 1.5GB minimum, which is not enough in my case. 
  
  The solution on my installation was to switch from 32bit to 64bit version of PHP. Reason is simple, to get more than 2GB memory available. When I run composer with command:
  
  php -d memory_limit=-1 composer.phar update --profile -vvv
  
  It gives me at the end of success run this result: Memory usage: 322.37MB (peak: 1804.41MB), time: 178.78s
  
  So memory usage is really high and maybe is time to talk about necessity to use composer with PHP 64bit as 32bit has 2GB memory limitation. I went through so many discussion about this issue but mostly there is no solution. As this issue is here so long time and obviously I am not alone should be nice to update official documentation to mention this option.
  
  Thank you, love composer so much!
  
  Best regards, Lukas
events.type: comment
events.action: created
events.author: zayders
events.masked_author: username_0
events.text: Hi @username_1  @username_2 , thanks for your reply, due to restriction of my IT department, i'm on Windows 7 32 bit, is there any problem to install php 64 bit on OS 32 bit ? I think it's not the better thing to do but i don't really know. If it's a problem, maybe i could ask them to pass on OS 64 bit. I have a lot of restriction, it's complicated.
events.type: comment
events.action: created
events.author: myspulin
events.masked_author: username_2
events.text: Hi @username_1 , you can't run 64bit PHP on 32bit OS, but regarding your restriction, there is a way to use some kind of virtualization. For example VirtualBox supports 64-bit guest operating systems, even on 32-bit host operating systems. So I beleave this should be your first option. Le tme know.
events.type: comment
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: I already switched to 64-bit PHP executable and now Composer is telling me that at 3.174 gibibytes it still needs an additional 512 MiB. The German error message says that my page file is too small to continue. Why would Composer need so much memory? My `require` section isn't that huge:
  
      "require": {
          "php": "^7.0",
          "sulu/sulu": "^1.6.3",
          "twig/extensions": "^1.0",
          "symfony/monolog-bundle": "^2.4",
          "sensio/distribution-bundle": "^5.0",
          "sensio/framework-extra-bundle": "^3.0.2",
          "incenteev/composer-parameter-handler": "^2.0",
          "dantleech/phpcr-migrations-bundle": "0.1.*",
          "zendframework/zend-stdlib": "^2.3",
          "zendframework/zendsearch": "@dev",
          "massive/build-bundle": "^0.3",
          "jackalope/jackalope-doctrine-dbal": "^1.2.5",
          "jackalope/jackalope-jackrabbit": "^1.2.0",
          "doctrine/doctrine-fixtures-bundle": "2.2.*",
          "doctrine/doctrine-bundle": "^1.0",
          "doctrine/doctrine-cache-bundle": "^1.0",
          "oro/doctrine-extensions": "^1.0",
          "sensio/generator-bundle": "^3.0",
  
          "sulu/theme-bundle": "^1.2",
          "symfony/assetic-bundle": "^2.0",
          "matthiasmullie/minify": "^1.3"
      },
  
  @username_1 You recommend "I would suggest you try to narrow your constraints as much as possible." 
  Doesn't that defeat the point of Composer and its SAT solver if I have to specify exact versions and keep track of updates manually? Or how could the above composer file be improved for this?
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: Of course that defeats the purpose, but it's also exactly inherent of SAT solving that it tries to find an optimal solution for the presented constraints, and their constraints, and their constraints. You should keep in mind that if you specify a Semver constraint on a package allowing 10 possible versions, that *each of those 10 may have different dependencies and constraints themselves*. So a solution may, even with very small require lists, require millions of solutions to be evaluated before an acceptable one is found.
  
  So yes, it defeats the purpose of SAT to artificially limit the number of possible solutions by narrowing down constraints. The alternative is to keep adding RAM until all possible solutions fit. You can't have both.
  
  In your specific case - Doctrine Bundle is at 1.10, specifying `^1.10` would eliminate about 20 candidates. Doctrine Cache Bundle is at 1.3.5, specifying `^1.3.5` would eliminate about 25 candidates. By specifying `^1.0` for both you are forcing Composer to evaluate 20*25 = about 500 (!) times as many root package permutations, and all their own recursive dependencies, than strictly necessary. So yes, by applying similar logic to all your includes you can likely make it work with less than 2GB again, and resolve a solution 10+ times faster as well. On a require list that's obviously an application and not a library, and as such has no need whatsoever to maintain support for all those bundle versions.
  
  As a practical developer I'd go with the advice to make it a lot faster and use a lot less memory despite the theoretically entirely correct statement that SAT should resolve the exact same solution.
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: There may actually be a use case I think to have a `composer optimize` command, which takes root constraints like this and makes them a ton more efficient by rewriting them from the lock file. So if, in this specific case, `doctrine/doctrine-cache-bundle` was resolved to 1.3.5 in a successful solution, we could replace the constraint safely with `^1.3.5` and it would by definition produce the same solution.
  
  Potential risk would be people running it on libraries as well which could be dangerous, but we could print some nasty warnings if `composer.json` type is not `project`.
  
  @username_7 whatcha think of this?
events.type: comment
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: Now that's a great idea. I've done so here and there, updating constraints to newer versions but not excessively. This is a rather long-running project which saw it's first incarnation in April 2017. Some dependencies haven't been updated since in the `composer.json`.
  
  But I can totally live with that recommendation, often update your constraints to exclude older versions that are irrelevant. If Composer would ship a command to do that on `"type": "project"` like you sketched out, that would be wonderful!
  
  By the way, I was able to successfully update now after closing everything else down. Composer peaked at 5,780 MiB RAM usage for quite a few minutes but it worked.
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: Just did a practical test on a huge Symfony application I'm working on, running `composer update --profile` with 65 root dependencies including dev:
  ```
  [383.7MB/105.42s] Memory usage: 383.74MB (peak: 771.84MB), time: 105.42s
  ```
  Not even 800MB of peak memory usage, less than 2 minutes. Just by occasionally narrowing down constraints when upgrading.
  
  (disclaimer: 65 dependencies including 25-something Symfony 4.x components managed by Symfony Flex which has its own optimizations).
events.type: comment
events.action: created
events.author: xabbuh
events.masked_author: username_5
events.text: @username_4 Your suggestion reminds me of #7273.
events.type: comment
events.action: created
events.author: iltar
events.masked_author: username_6
events.text: Recently I ran into this issue again, turns out the fix was indeed to narrow down the possible constraints again.
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: It would likely make the process more than 10 times faster with 10% of the RAM. Feel free to issue a PR   😉
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: @username_3 did you update your Composer version recently? I just tried `composer update --profile` on the unoptimized `composer.json` you provided above in a VM without any caches so it had to download everything, and got this:
  ```
  [374.5MB/379.78s] Memory usage: 374.55MB (peak: 1841.85MB), time: 379.78s
  ```
  That's less than a third of what you claim your optimized version is using. Could it be that your `composer.phar` is as old as the project?   😉
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: I decided to continue the test. After the above solution, I checked which versions of root packages were resolved:
  ```
  dantleech/phpcr-migrations-bundle    0.1                PHPCR migrations bundle
  doctrine/doctrine-bundle             1.10.0             Symfony DoctrineBundle
  doctrine/doctrine-cache-bundle       1.3.5              Symfony Bundle for Doctrine Cache
  doctrine/doctrine-fixtures-bundle    v2.2.1             Symfony DoctrineFixturesBundle
  incenteev/composer-parameter-handler v2.1.3             Composer script handling your ignored parameter file
  jackalope/jackalope-doctrine-dbal    1.3.2              Jackalope Transport library for Doctrine DBAL
  jackalope/jackalope-jackrabbit       1.3.2              Jackalope Transport library for Jackrabbit
  massive/build-bundle                 0.3.1              Massive Art Build Bundle
  matthiasmullie/minify                1.3.61             CSS & JavaScript minifier, in PHP. Removes whitespace, strips comments, combines files (incl. @import statements and small assets in CSS files), and optimizes/shortens a few commo...
  oro/doctrine-extensions              1.2.2              Doctrine Extensions for MySQL and PostgreSQL.
  sensio/distribution-bundle           v5.0.24            Base bundle for Symfony Distributions
  sensio/framework-extra-bundle        v3.0.12            This bundle provides a way to configure your controllers with annotations
  sensio/generator-bundle              v3.1.7             This bundle generates code for you
  sulu/sulu                            1.6.23             Sulu core distribution
  sulu/theme-bundle                    1.3.2              The Sulu Bundle which provides themes
  symfony/assetic-bundle               v2.8.2             Integrates Assetic into Symfony2
  symfony/monolog-bundle               v2.12.1            Symfony MonologBundle
  twig/extensions                      v1.5.4             Common additional features for Twig that do not directly belong in core
  zendframework/zend-stdlib            2.7.7             
  zendframework/zendsearch             dev-master c8de250 a general purpose text search engine written entirely in PHP 5
  ```
  And adapted my `composer.json` accordingly, ,following the "rules" I outlined above only replacing pure caret constraints with the resolved version:
  ```json
  "require": {
      "php": "^7.0",
      "sulu/sulu": "^1.6.23",
      "twig/extensions": "^1.5.4",
      "symfony/monolog-bundle": "^2.12.1",
      "sensio/distribution-bundle": "^5.0.24",
      "sensio/framework-extra-bundle": "^3.0.12",
      "incenteev/composer-parameter-handler": "^2.1.3",
      "dantleech/phpcr-migrations-bundle": "0.1.*",
      "zendframework/zend-stdlib": "^2.7.7",
      "zendframework/zendsearch": "@dev",
      "massive/build-bundle": "^0.3.1",
      "jackalope/jackalope-doctrine-dbal": "^1.3.2",
      "jackalope/jackalope-jackrabbit": "^1.3.2",
      "doctrine/doctrine-fixtures-bundle": "2.2.*",
      "doctrine/doctrine-bundle": "^1.10.0",
      "doctrine/doctrine-cache-bundle": "^1.3.5",
      "oro/doctrine-extensions": "^1.2.2",
      "sensio/generator-bundle": "^3.1.7",
  
      "sulu/theme-bundle": "^1.3.2",
      "symfony/assetic-bundle": "^2.8.2",
      "matthiasmullie/minify": "^1.3.61"
  }
  ```
  It got a lot faster, but indeed not much less RAM:
  ```
  [374.6MB/113.96s] Memory usage: 374.59MB (peak: 1741.24MB), time: 113.96s
  ```
  At which point I realized something that was bugging me before about the `composer.json` you provided - there was no explicit mention of Symfony anywhere, you're depending on a full stack Symfony version being decided on recursively, which eventually leads to `symfony/symfony:2.8.49` being installed. This is highly dangerous, as many of those libraries are compatible with a lot of Symfony versions (ie. `^2.8 || ^3.2 || ^4.0`, or `>2.8` or similar incredibly wide constraints, given the amount of releases Symfony has. This is more or less the exact reason Symfony Flex was developed, to battle the sheer amount of Symfony packages Composer has to consider that are compatible with hundreds of other packages.
  
  So I added a single line to your require list:
  ```
      "symfony/symfony": "^2.8.49"
  ```
  And ran `composer update --profile` again:
  ```
  [341.0MB/12.23s] Memory usage: 340.96MB (peak: 1172.99MB), time: 12.23s
  ```
  Achievement unlocked - from 380 seconds down to 12 with 2 simple optimizations aimed at making Composer's life easier   😉 
  
  This leaves the question why in 12 seconds it's still using 1.2GB of RAM. The answer to that is also simple actually - Composer is optimized towards up to date development. It downloads and processes package info for the last 3 months first, and starts to load older data incrementally as it turns out to be needed by the solver. This way in the case of Symfony for example it can skip years of outdated versions if you're just working with the current 4.2 release. In your case you *are* using 3 year old dependencies, giving it little other choice than to "waste" over a GB of RAM on more or less the past 5 years of Packagist releases. Hence why my much bigger project only used 778MB of RAM - it's on Symfony 4.2 with cutting edge dependencies.
  
  Hope this all explains a lot, and happy coding now your `composer update` only takes 10~12 seconds   😆
events.type: comment
events.action: created
events.author: zayders
events.masked_author: username_0
events.text: Hi everyone ! I had possibility to have a new OS version : x64 and to upgrade my php to 7.2 in x64. It solve my problem, i can run any command with composer. My computer is still the same, 4Go RAM but with OS and PHP x64 (7.2).
  So it works perfectly with `php -d memory_limit=-1 ../composer.phar update`
  
  Thanks for your help !
events.type: comment
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: No, it's 1.8.0 😄 I update Composer regularly.
  
  I did, however, do some research as well. Since I wanted to know where the Symfony dependency comes from, but for a totally different reason: I was wondering why it was still at 2.8 when my other Sulu projects are at 3.4 already. It turns out, in this project we used `sulu/sulu` but since have started our newer projects with `sulu/sulu-minimal` (as recommended by [the Sulu documentation](http://docs.sulu.io/en/latest/book/getting-started.html)). I think this might be a lead I will try to explore next, drop the full CMF framework dependency and only require `sulu-minimal` and what I really need.
events.type: comment
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: Sulu does however have a lot of dev dependencies for the full package: https://packagist.org/packages/sulu/sulu
  
  I didn't think about dev dependencies, because the only one in my project is:
  
      "require-dev": {
          "phpcr/phpcr-shell": "^1.1.1"
      },
  
  But just now I took another good look at what `sulu/sulu` requires for dev. Running `composer update --no-dev --profile` yields similar values, though.
events.type: comment
events.action: created
events.author: Seldaek
events.masked_author: username_7
events.text: Gonna close this because we have https://github.com/composer/composer/issues/7273 open and also because Composer 2.0 will behave quite differently there so I think let's give it some time and see what comes of that effort. In the meantime yes please restrict your constraints manually as much as possible, that'll help.
events.type: comment
events.action: closed
events.author: Seldaek
events.masked_author: username_7
events.type: issue
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: Requiring Symfony explicitly indeed reduced the runtime a lot (half of that time is spent in the post-update-scripts) and memory usage by 37%:
  
      [511.1MB/201.09s] Memory usage: 511.13MB (peak: 3774.46MB), time: 201.09s
  
  Thanks for your analysis!
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: `composer why symfony/symfony`   😉
events.type: comment
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: No, I used `composer why-not symfony/symfony:3.4` 😛
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: Both would show the problem, as the first one will list all recursive requirements causing the package to be selected, with their respective constraints.
events.type: comment
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: Funny. This week I pegged the Symfony version to "3.4.20" as a quick fix because 3.4.21 broke another dependency. This resulted in a much lower memory usage of 2,071 MB peak RAM usage instead of the 3.7 or 4+ GB I was seeing before. Today I set it back to "^3.4.21" because the bug was fixed and now `composer update` is memory heavy again. If there is only one version that applies to the range "^3.4.21", why is there a difference between setting the exact version and using the ^ operator?
  Could this be optimized to the point where there is a check if the range with regards to the chosen stability setting resolves to exactly one version and then use this version as if it were set without a range?
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: The behavior you describe surprises me, I have no clue why it would work like this. Makes me curious to see whether it's reproducable with for example `^3.4.18` and `3.4.18` right now (following your theory it would be 4 times more inefficient).
events.type: comment
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: Dang, sorry. I can't reproduce this now. I guess the additional memory usage came from Composer having to really update Symfony to 3.4.21. If I run the `composer.json` with profiling and debugging enabled, the memory usage and runtime is almost equal between "3.4.21" and "^3.4.21":
  
  ```
  [343.8MB/13.51s] Reading C:/Users/jwagner.AD/AppData/Local/Composer/repo/https---repo.packagist.org/provider-zendframework$zendsearch.json from cache
  [1459.2MB/48.02s] After getRulesFor
  [1459.3MB/48.03s] After checkForRootRequireProblems
  [1459.3MB/48.03s] After new Decisions
  [2065.5MB/54.18s] Resolving dependencies through SAT
  [2070.7MB/54.29s] Looking at all rules.
  [2071.1MB/56.52s] [2071.4MB/58.71s] Something's changed, looking at all rules again (pass #2)[2071.4MB/58.71s]          [2071.4MB/60.88s] Something's changed, looking at all rules again (pass #3)[2071.4MB/62.10s]
  [2071.4MB/62.10s] Dependency resolution completed in 7.921 seconds
  [2071.4MB/62.16s] Analyzed 20792 packages to resolve dependencies
  [2071.4MB/62.16s] Analyzed 3401876 rules to resolve dependencies
  [2071.4MB/62.16s] Nothing to install or update
  ```
  
  But by digging into the code, I gained a valuable insight: The SAT solver itself isn't the memory hog, it's `RuleSetGenerator->getRulesFor`.
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: That generates the rules for SAT to solve to use so technically it's the same  😉
events.type: comment
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: Semantics. 😛 
  
  I think I was chasing gremlins, I tried your suggestion with ^3.4.18 and then with 3.4.18 and it had about the same footprint, even though there was a downgrade on the latter `update`. Even though there were 34,689 more rules to resolve, this 1% increase was hardly noticable.
  
  ^3.4.18:
  ```
  [343.7MB/9.56s] Reading C:/Users/jwagner.AD/AppData/Local/Composer/repo/https---repo.packagist.org/provider-zendframework$zendsearch.json from cache
  [1464.7MB/41.68s] After getRulesFor
  [1464.7MB/41.68s] After checkForRootRequireProblems
  [1464.7MB/41.69s] Before building watch graph
  [2076.8MB/47.27s] After building watch graph
  [2076.8MB/47.86s] Resolving dependencies through SAT
  [2082.0MB/47.96s] Looking at all rules.
  [2082.4MB/50.40s] [2082.6MB/52.66s] Something's changed, looking at all rules again (pass #2)[2082.6MB/52.66s]          [2082.6MB/54.90s] Something's changed, looking at all rules again (pass #3)[2082.6MB/56.55s]
  [2082.6MB/56.55s] Dependency resolution completed in 8.688 seconds
  [2082.7MB/56.62s] Analyzed 20792 packages to resolve dependencies
  [2082.7MB/56.62s] Analyzed 3436565 rules to resolve dependencies
  [2082.7MB/56.62s] Nothing to install or update
  ```
  3.4.18:
  ```
  [343.7MB/9.58s] Reading C:/Users/jwagner.AD/AppData/Local/Composer/repo/https---repo.packagist.org/provider-zendframework$zendsearch.json from cache
  [1459.0MB/46.31s] After getRulesFor
  [1459.1MB/46.31s] After checkForRootRequireProblems
  [1459.1MB/46.31s] Before building watch graph
  [2065.3MB/52.27s] After building watch graph
  [2065.3MB/52.80s] Resolving dependencies through SAT
  [2070.5MB/53.08s] Looking at all rules.
  [2070.9MB/55.23s] [2071.2MB/57.44s] Something's changed, looking at all rules again (pass #2)[2071.2MB/57.44s]          [2071.2MB/59.58s] Something's changed, looking at all rules again (pass #3)[2071.2MB/60.88s]
  [2071.2MB/60.88s] Dependency resolution completed in 8.076 seconds
  [2071.2MB/61.05s] Analyzed 20792 packages to resolve dependencies
  [2071.2MB/61.05s] Analyzed 3401876 rules to resolve dependencies
  [2072.0MB/61.06s] After setupInstalledMap
  [2072.6MB/61.08s] After getRulesFor
  [2072.6MB/61.08s] After checkForRootRequireProblems
  [2072.6MB/61.08s] Before building watch graph
  [2072.8MB/61.08s] After building watch graph
  [2072.8MB/61.08s] Resolving dependencies through SAT
  [2072.9MB/61.09s] Looking at all rules.
  [2072.9MB/61.09s]
  [2072.9MB/61.09s] Dependency resolution completed in 0.002 seconds
  [2071.8MB/61.09s] Package operations: 0 installs, 1 update, 0 removals
  [2071.8MB/61.09s] Updates: symfony/symfony:v3.4.18
  [2071.8MB/61.10s]   - Downgrading symfony/symfony (v3.4.21 => v3.4.18)
  [...]
  [399.9MB/212.23s] Memory usage: 399.89MB (peak: 2081.94MB), time: 212.23s
  ```
events.type: comment
events.action: created
events.author: curry684
events.masked_author: username_4
events.text: Yep, that's what I would expect to see, as the constraint covers 3 more versions it causes a few more rules to be generated, but as all 4 have the same dependencies themselves it shouldn't really impact the whole process a lot.l
events.type: comment
events.action: created
events.author: shadman
events.masked_author: username_8
events.text: You may also get resolved by just removing vendor directory and re-execute composer install command.
events.type: comment
events.action: created
events.author: vinika02
events.masked_author: username_9
events.text: Hi, this solution will fix your problem.
  
  Update your php.ini file then restart Apache or your server
  
  It's work on me.
events.type: comment
events.action: created
events.author: vinika02
events.masked_author: username_9
events.text: Hi, this solution will fix your problem.
  
  Update your php.ini file then restart Apache or your server
  example:
  memory_limit=128M
  to 
  memory_limit=1128M
  
  
  It's work on me.
events.type: comment
events.action: created
events.author: YetiCGN
events.masked_author: username_3
events.text: Wouldn't work for me, as you see above, because Composer needs over 6 GB of RAM. You can set it to unlimited with `-1` as well. Still you might hit a hardware memory limit.
events.type: comment