Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65891
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain zend.com does not designate 209.85.219.47 as permitted sender)
References: <e8aaa4ce59a801e53c6abc9d287d1859@mail.gmail.com>
 <511BFC81.8020400@oracle.com> <7de2703f77537a47b457c4479a19ac3a@mail.gmail.com>
 <511D39EF.5060409@oracle.com> <511EBC83.9010003@oracle.com>
In-Reply-To: <511EBC83.9010003@oracle.com>
MIME-Version: 1.0
Thread-Index: AQHLvIAlSKZ5OJboBymrD0/yWmCdiQMxVgljATz3XvIBsPoeJgKUEqfJmDvdO5A=
Date: Sat, 16 Feb 2013 21:16:49 +0200
Message-ID: <0b00bdce214246c3fbca122e1e09a260@mail.gmail.com>
To: Christopher Jones <christopher.jones@oracle.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] Zend Optimizer+ Source Code now available
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Christopher Jones [mailto:christopher.jones@oracle.com]
> Sent: Saturday, February 16, 2013 12:54 AM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: RE: [PHP-DEV] Zend Optimizer+ Source Code now available
>
>
>
> Hi Zeev,
>
> I think people are keen to see Optimizer+ merged.  Hopefully the RFC can
> set
> expectations clear on what the short-term steps will be, and what the
> bigger
> picture might look like.  The middle-term tasks will then work themselves
> out as
> we get to them (in true PHP fashion)
>
> - What does "Integrate Optimizer+ into PHP, but don=E2=80=99t delay 5.5.0=
 for
>    it" mean?  Does it mean:
>
>     * Work really had to get it into PHP 5.5.0 with no delay to 5.5?
>     * Include it in /ext "as-is", i.e. perhaps no ZTS support, or marked
> EXPERIMENTAL?
>     * Include it in PHP 5.5.x where x > 0, when Optimizer+ is complete?
>
>    The slippage of 5.5 is an issue to some people, so clarity here
>    would be good.

It's in the context of this, one paragraph above it:

"The question on the table is whether most users would prefer a slightly
later release with an out-of-the-box working opcode cache, or a slightly
earlier release without a compatible opcode cache available for several
additional months."

In other words, this option mean that if we can't integrate it without
delaying 5.5.0, we don't integrate it.  By integration I refer to including
something that is production quality, potentially enabled-by-default (TBD),
that everyone should feel comfortable using.

>    I believe the wider community is expecting the op-code cache to
>    "just work", so if that's not the case, the RFC should communicate
>    this clearly.  There's also the potential to damage Zend's
>    reputation if what is released doesn't work well.

I agree, although an opcode cache does add an extra layer of complexity, so
it does stand the chance to break otherwise working setups (the same can
happen with other opcode caches).  It should be a rare occurrence, with the
performance advantage far outweighing it.

> - What are your general thoughts about its integration architecture
>    and the potential for alternative op-code caches to be used?  I know
>    code can always be changed, but what (if any) design will happen
>    from the start to make this easy?

I'm not sure.  The level of integration we're talking about for 5.5.0, due
to the haste, is not going to be beyond a mostly soft-bundle, at most
something that gets enabled by default - but can still be disabled or
outright removed.  That means that you should be able to replace it with an=
y
other opcode cache you might want.

However, for the future, there *might* be potential for further gains we
might be able to get from tighter integration between the different layers.
At this point I don't have any concrete ideas, though, so it's possible it'=
s
only theoretical.  Regardless, such tighter integration - that would
preclude other opcode caches from being used - will have to be the subject
of a separate RFC & vote.

I'll clarify that point too in the RFC.

> - Regarding name choice, here are some: ZopCache, Cachze, RunCachze.

Interesting names, I'm curious about pronunciation :)

Zeev