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
On Wed, Oct 23, 2019 at 5:42 PM Dmitry Stogov
<[email protected]<mailto:[email protected]>> wrote:
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
________________________________
From: Dmitry Stogov <[email protected]<mailto:[email protected]>>
Sent: Tuesday, October 22, 2019 15:38
To: Nikita Popov <[email protected]<mailto:[email protected]>>; PHP
internals <[email protected]<mailto:[email protected]>>
Subject: Re: [PHP-DEV] Re: [RFC] Union Types v2
Hi Nikita,
Can you please give me one/two days, before starting the voting, for
implementation review (at least until October 25),
Thanks. Dmitry.
________________________________
From: Nikita Popov <[email protected]<mailto:[email protected]>>
Sent: Tuesday, October 22, 2019 12:36
To: PHP internals <[email protected]<mailto:[email protected]>>
Subject: [PHP-DEV] Re: [RFC] Union Types v2
On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov
<[email protected]<mailto:[email protected]>> wrote:
> Hi internals,
>
> I'd like to start the discussion on union types again, with a new proposal:
>
> Pull Request: https://github.com/php/php-rfcs/pull/1
> Rendered Proposal:
> https://github.com/nikic/php-rfcs/blob/union-types/rfcs/0000-union-types-v2.md
>
> As an experiment, I'm submitting this RFC as a GitHub pull request, to
> evaluate whether this might be a better medium for RFC proposals in the
> future. It would be great if we could keep the discussion to the GitHub
> pull request for the purpose of this experiment (keep in mind that you can
> also create comments on specific lines in the proposal, not just the
> overall discussion thread!) Of course, you can also reply to this mail
> instead. The final vote will be held in the wiki as usual.
>
> Relatively to the previous proposal by Bob&Levi (
> https://wiki.php.net/rfc/union_types), I think the main differences in
> this proposal are:
> * Updated to specify interaction with new language features, like full
> variance and property types.
> * Updated for the use of the ?Type syntax rather than the Type|null
> syntax.
> * Only supports "false" as a pseudo-type, not "true".
> * Slightly simplified semantics for the coercive typing mode.
>
> Regards,
> Nikita
>
An implementation of this proposal is now available at
https://github.com/php/php-src/pull/4838. As the implementation didn't turn
up any new issues, I think it's time to move this RFC forward to voting.
Nikita
CAUTION: This email originated from outside of the organization. Do not click
on links or open attachments unless you recognize the sender and know the
content is safe.
CAUTION: This email originated from outside of the organization. Do not click
on links or open attachments unless you recognize the sender and know the
content is safe.
