It is known that composer update takes a lot of memory: #5915, #5902,
I am playing with a profiler (@blackfireio) to make a demo in my local
PHP meetup (@phpvigo) and I found out a way to use less memory. These
are my first tests:
* Private project using PHP 5.6:
* Memory: from 1.31GB to 1.07GB
* Wall Time: from 2min 8s to 1min 33s
* symfony-demo using PHP 7.1 in my old mac book:
* Memory: from 667MB to 523MB
* Wall Time: from 5min 29s to 5min 28s
Not use an array inside conflict rules is this improvement main idea:
```php
<?php
//Memory 38MB
gc_collect_cycles();
gc_disable();
class Rule
{
public $literals;
public function __construct(array $literals)
{
$this->literals = $literals;
}
}
$rules = array();
$i = 0;
while ($i<80000){ //
$i++;
$array = array(-$i, $i);
$rule = new Rule($array);
$rules[] = $rule;
}
```
```php
<?php
//Memory 11.1MB
gc_collect_cycles();
gc_disable();
class Rule2Literals
{
public $literal1;
public $literal2;
public function __construct($literal1, $literal2)
{
$this->literal1 = $literal1;
$this->literal2 = $literal2;
}
}
$rules = array();
$i = 0;
while ($i<80000){ //
$i++;
$rule = new ConflictRule(-$i, $i);
$rules[] = $rule;
}
```
More info https://github.com/composer/composer/pull/6168
The former implementation used the 'src' endpoint which returned some meta data as well.
This has been replaced with the 'raw' endpoint which does not return the meta data and does not need an extra JSON decode step.
Store the Bitbucket access-token (and the expiration time) so it can be re-used within the time it is valid.
The Bitbucket::requestToken and Bitbucket::getToken now only return the access-token and not all other parameters it receives from the Bitbucket API.
commit 3994b556dcffcde7b1801c8bc712f3127e8f8e7c
Author: John Whitley <john.whitley@berea.eu>
Date: Tue Aug 16 09:02:53 2016 +0100
https://github.com/composer/composer/issues/5600
This alters the default flag for loadOptions in
\Composer\Package\Loader\ArrayLoader to true; and alters the assumption
of the test to reflect this change.
**Rationale**
The `\Composer\Package\Loader\ArrayLoader` test (defined in
tests/Composer/Test/Package/Loader/ArrayLoaderTest.php) assumed that a
new `\Composer\Package\Loader\ArrayLoader` instance would be always
created with the optional flag loadOptions set to true.
```php
$this->loader = new \Composer\Package\Loader\ArrayLoader(null, true);
```
This change alters the general case to reflect the default assumption as
defined in the test.
commit b75fc4ad7238bc50f724bd29446ccbc33e82c34c
Author: John Whitley <john.whitley@berea.eu>
Date: Mon Aug 15 16:55:27 2016 +0100
Altered the test for ArrayLoader to use the default loadConfig flag, and to test the true and false states for the loadConfig flag
Projects that add binaries to `vendor-bin` can now execute those via the same command as projects that consume them without installing them first.
In list overview local commands have a `(local)` tag to distinguish them from commands installed in `vendor-bin`.
Local binaries take precedence over `vendor-bin` which takes precedence over binaries in path.