Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82900
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.108 as permitted sender)
Message-ID: <BLU436-SMTP151E12D0D6F709DCC26B14DE22E0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DCFE6091-B5B9-4F11-817D-37BAF56F2822"
Date: Tue, 17 Feb 2015 00:04:29 +0100
To: PHP Internals <internals@lists.php.net>
MIME-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
Subject: Switch jumptable optimization
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_DCFE6091-B5B9-4F11-817D-37BAF56F2822
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

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=

--Apple-Mail=_DCFE6091-B5B9-4F11-817D-37BAF56F2822--