Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82931
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP151E12D0D6F709DCC26B14DE22E0@phx.gbl>
References: <BLU436-SMTP151E12D0D6F709DCC26B14DE22E0@phx.gbl>
Date: Tue, 17 Feb 2015 10:46:24 +0400
Message-ID: <CA+9eiLsuo9ZaLiWsSciXN6ZBLT0d=7za9hO+utriREYkWT7MPA@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01628326b537b9050f430f90
Subject: Re: [PHP-DEV] Switch jumptable optimization
From: dmitry@zend.com (Dmitry Stogov)

--089e01628326b537b9050f430f90
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 17, 2015 at 2:04 AM, Bob Weinand <bobwei9@hotmail.com> wrote:

> I'd like to show you my recent work on a jumptable optimization for
> switches.
>
> https://github.com/php/php-src/pull/1048 <
> https://github.com/php/php-src/pull/1048>
>
> It is a fully transparent optimization of switches, by putting a new
> ZEND_SWITCH opcode at the top of the switch in case we can build a
> jumptable, which is the case if the cases are only scalars (no doubles) or
> evaluate to them at compile-time.
>
> Switches tend to be big sometimes with a lot of static (literals or
> constants usually) cases, which was a comparison for each case, and now
> just a simple hashtable lookup is needed, which greatly improves
> performance. In case where the result of the switch can be determined at
> compile-time, it even replaces the comparisons with a simple ZEND_JMP
> opcode.
>
> In synthetic benchmarks the results are mind blowing, but in practice,
> benefits mostly are stateful userland parsers (often called with sometimes
> big switches), where it makes it a few percent faster. (For more concrete
> numbers see https://github.com/php/php-src/pull/1048#issuecomment-73032647
> )
>
> As the optimization is only done if there are 3 or more cases, the lookup
> is always faster than the single comparisons. So there's no negative
> performance impact.
>
> It already works, except with opcache where the CFG optimization pass
> still lacks support. Dmitry or Laruence volunteered to add support for
> opcache.
>
> I'd like to know if there are any technical objections to the PR. If not,
> they will add opcache support and merge it in.
>
> Thanks,
> Bob


The patch looks interesting.
We will implement support for opcache and then analyze its impact on
performance.
I see it as a self-containing feature that won't affect anyone  (except
opcache and may be debuggers).
I'm not going to work on it in nearest days or weeks, because of more
critical tasks.

Thanks. Dmitry.

--089e01628326b537b9050f430f90--