Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107693
MIME-Version: 1.0
References: <CAF+90c8EvfFPqjRJjJ3T-qTfLiWn7aZzCrGpk7R3yNFLT1qWjQ@mail.gmail.com>
 <CAF+90c9ZVt+ig91DSazjf59uysKFFkCiEDhMLgLSaw4KApuBfg@mail.gmail.com>
 <MN2PR02MB5775DDEA6332048DB9C9E52EBF680@MN2PR02MB5775.namprd02.prod.outlook.com>
 <MN2PR02MB577594376F687FC7C789B689BF6B0@MN2PR02MB5775.namprd02.prod.outlook.com>
In-Reply-To: <MN2PR02MB577594376F687FC7C789B689BF6B0@MN2PR02MB5775.namprd02.prod.outlook.com>
Date: Fri, 25 Oct 2019 12:22:12 +0200
Message-ID: <CAF+90c9-gnymdh3S9UYO=b-bEmibGxMt_25eF8QbUmxEjFstkA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f363f10595b9862c"
Subject: Re: [PHP-DEV] Re: [RFC] Union Types v2
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000f363f10595b9862c
Content-Type: text/plain; charset="UTF-8"

On Wed, Oct 23, 2019 at 5:42 PM Dmitry Stogov <dmitry@zend.com> 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 <dmitry@zend.com>
> *Sent:* Tuesday, October 22, 2019 15:38
> *To:* Nikita Popov <nikita.ppv@gmail.com>; PHP internals <
> internals@lists.php.net>
> *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 <nikita.ppv@gmail.com>
> *Sent:* Tuesday, October 22, 2019 12:36
> *To:* PHP internals <internals@lists.php.net>
> *Subject:* [PHP-DEV] Re: [RFC] Union Types v2
>
> On Wed, Sep 4, 2019 at 10:26 AM Nikita Popov <nikita.ppv@gmail.com> 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.
>

--000000000000f363f10595b9862c--