__callStatic: cache created Enum instances

[danielbeardsley]

Instead of creating a new one each time, cache them.

This only matters if you're creating thousands of these objects.

I've used a small test script:

<?
require './vendor/autoload.php';

class Fast extends MyCLabs\Enum\Enum {
   protected const VALUE_ONE = "one";
   protected const VALUE_TWO = "two";
}

$t = microtime(true);
for ($i = 0; $i < 1000; $i++) {
   Fast::VALUE_ONE();
}
$secondsPerOp = (microtime(true) - $t) / 1000;
var_dump("Microseconds per op: " . $secondsPerOp * 1000000);

Before this change, we were getting about 4us per operation,
after this, we get about 1us per op, a 4X speedup!!

Note: This only matters if you end up constructing thousands of these
objects. We end up using this library extensively and thus end up
incurring more than ten milliseconds per request just for Enum
construction.

[danielbeardsley]

Not sure why travis isn't enabled on this repo... there's a travis.yml config. Either way, passes 100%

[willemstuursma]

Maybe it is good to return a clone of the cached instance, so no one will accidentally use === to compare enums.

[danielbeardsley]

so no one will accidentally use === to compare enums

That's a good point. People might accidentally start using that if they are literally the same instances.

Pushed a commit.

Performance gains still intact:

[willemstuursma]

LGTM, for what it's worth @mnapoli.

[mnapoli]

Let's do it, thanks all!

[rodion-k]

Maybe it is good to return a clone of the cached instance, so no one will accidentally use === to compare enums.

Why is it bad to use === to compare enums?

[danielbeardsley]

Because your code would then functionally depend on caching to be correct. If caching changed, your code would break.