Slow aliases and factory set methods

[malinink]

In new SM3 there is couple of methods that are more slowly than in SM2

Difference in time is great (about 8x slower on this method)
All other comparisons I provide exactly on that function.

The reason is that is it a lot of factories and aliases that pass to SM with functions setAlias and setFactory. Behind the scene one key value pair meld with config in configure method.

I see 2 ways to solve problem:

• add functions such as setAliases and etc...

public function setAliases($aliasTargetPairs)
{
    $this->configure(['aliases' => $aliasTargetPairs]);
}

• Modify function setAlias to something like that: it was a bad idea, skip that

public function setAlias($alias, $target)
{
    $this->validateOverrides(['aliases' => [$alias => $target]]);
    $this->aliases[$alias] = $target;
}

First one is more elegant and have maximum speed(10x faster then in SM2, 75x faster current SM3). But we need to rewrite other components.
Second one is twice slower than SM2, but there is no need to modify other components.

Of course we could apply both of them.
I think that first one is best idea, I would like to provide PR for this issue, if it is resonable.

Also I could provide PR to to 2.7 branch of SM witch allows modify other components to use that methods.

[malinink]

After some checks I found that:

• main problem is in calling resolveAliases in configure method at bad condition
• resolveAliases could be optimized for case when new aliases do not intersect with aliases that already present in SM.

I'll provide PR that consists both of changes.
Also I add one more test for recursive aliases and benchmark for set methods.

All changes that provide my PR improve set methods speeding and does not affect the speed of the other SM methods.

setFactory is now 9x faster
setAlias (for not intersecting case) is 3x faster

[malinink]

Also it is still a good question is it a good idea to add

public function setAliases($aliasTargetPairs)
{
    $this->configure(['aliases' => $aliasTargetPairs]);
}

and setFactories methods.

Now only two classes will have improvements of that:

• first
• second

As a result we will have much faster load of application.

[snapshotpl]

Great improvement!

[malinink]

I provide PR with setAliases and setFactories methods for both master and release-2.7 branches

[weierophinney]

There's no reason for the new methods on v3, as you can use configure () already to accomplish the same thing. As for v2, we do not want to add new features at this time, unless they aid with migration to v3.

[malinink]

@weierophinney
For example here
We should use something like that?

$serviceManager->configure([
    'factories' => $this->factories,
]);

I thought it was a bad idea.

Nevertheless, I move setAliases/setFactories methods to another PR. (should I close them?)
P.S. with new SM3 default mvc application loads slower then with SM2, that was the main reason of that functions

The main PR do not add new features, just improvements.

[pine3ree]

@malinink

FYI, since it's related to an issue of mine (sorry I have read your issue report just now)

I had the same performance problems after migrating to zend-servicemanager3. After a little investigation I came to the same conclusion about setAlias and setFactory in vie helper config classes.

I added 2 PRs to solve the performance overhead for my use case.

• fix performance issues using sm3 configure() zend-form#77
• use sm3 configure when possible zend-i18n#47

These do not solve the slowness of those methods, just avoid using them when using service-manager3 and use its newly added batch configure() method instead.

related discussions:

• v3 performance while registering services factories and aliases #122
• zend-view-(extra-)helpers performance overhead zend-expressive-zendviewrenderer#25
• Question about (view) helpers' plugin aliases zend-form#76

kind regards

[malinink]

@pine3ree
Thanks for looking from another side on that problem. I will trace your PR, and will remove mine on merge.

[pine3ree]

@malinink
My PRs just circumvent the performance issues where they become very evident but they do not fix the slowness of v3 set(Alias|Factory) methods. So i believe you should keep your issue report / fixes open.

kind regards