Hi Nikita,

in your results, assignment to typed reference is ~3 time slower without JIT and ~10 times slower with JIT.

But this is not the worst case. I can simple craft a script where single assignment will lead to hundreds type checks.

<?php

class A {

public ?A $ref;

function __construct(&$ref = null) {

$this->ref =& $ref;

}

}

for ($i = 0; $i < 100; $i++) {

$a[$i] = new A($ref);

}

$ref = new A; // <= 100 type checks on a single assignment

?>

In case we add union types, we can make 200, 300 check...

The worst thing, for me, is variance together with union of multiple class types.

Each such method compatibility check is going to be a puzzle solving, and I imagine people, proud of writing "complex pearls".

My main concern, I don't like to complicate the language with features that shouldn't be often used, and I don't like to complicate implementation and reduce performance without real need.

In my opinion, union of standard types and single class or null should be enough for most typing use cases.

Thanks. Dmitry.

From: Nikita Popov [email protected]

Sent: Friday, October 25, 2019 13:22

To: Dmitry Stogov [email protected]

Cc: PHP internals [email protected]

Subject: Re: [PHP-DEV] Re: [RFC] Union Types v2

Hi Nikita,

I checked the Union Type implementation, and it more or less good. I mean, it implements the RFC in almost the best way.

However, as I don't like the RFC itself. Especially, unions of multiple classes and interference with type variance, I'll vote against this.

Actually, I think PHP already took wrong direction implementing "typed references" and "type variance".

Introducing more "typing", we suggest using it, but this "typing" comes with a huge cost of run-time checks.

From 10% (scalar type hint of argument) to 3 times (typed reference assignment) performance degradation.

Anyone may rerun my benchmarks https://gist.github.com/dstogov/fb32023e8dd55e58312ae0e5029556a9

Thanks. Dmitry.

For reference, here are the results I get with/without JIT: https://gist.github.com/nikic/2a2d363fffaa3aeb251da976f0edbc33

I think that union types don't really change much in terms of the performance calculus of type checking, because type checking is equally fast (or slow) for a single scalar type, and 5 different scalar types: they are all handled in a single bit check. The only case that is indeed somewhat slow is if multiple class types are used in the union, because we actually have to check each one until we find a match. I do hope that having unions with a large number of classes will not be common.

Generally, this area could use some more optimization from the implementation side. I spent a bit of time yesterday optimizing how we perform instanceof checks (the implementation was quite inefficient, especially for interfaces), which had a large positive impact on class type checks. There's more low hanging fruit like this, for example verify_return_type has no JIT implementation yet (which is why with JIT simple arg type checks have nearly zero overhead, while return type checks have a large overhead). Assignments to typed properties are also badly optimized, because everything is punted to the slow path, while we should be able to handle the simple cases with just one extra bit check, without going through the complex implementation that deals with things like weak typing coercions.

I do think that performance considerations are important when it comes to new typing features (which is why, for example, we have categorically rejected a "typed arrays" implementation that has to check all array elements), but don't see union types are particular problematic in that regard, beyond what we already have.

Nikita