Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92475
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain heroku.com designates 209.85.192.41 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <CAKSD0w6ji0JgnnU0BSCv64_bu+RNnLTRyz7XPyCv2gcK-+6BBg@mail.gmail.com>
Date: Tue, 19 Apr 2016 18:54:00 +0200
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <BC8389E7-E7BB-416D-96F4-4A73326C9DCC@heroku.com>
References: <CAKSD0w6ji0JgnnU0BSCv64_bu+RNnLTRyz7XPyCv2gcK-+6BBg@mail.gmail.com>
To: Lin Yo-An <cornelius.howl@gmail.com>
Subject: Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time
From: dz@heroku.com (David Zuelke)

I think this solution is merely a band-aid for a more profound =
architectural weakness of current PHP setups, where a web server call =
out to the engine (via embedding or FastCGI) to execute a script, which =
causes this recurring initialization overhead in the first place.

The future is (or should be) servers implemented fully in PHP code (e.g. =
PHP-PM), just like every other comparable language (Ruby, Python, Java, =
...) already does. That also brings many other benefits, such as the =
ability to handle upgrades to WebSockets in the same codebase, stream =
request bodies as they're being uploaded, and so forth.

And the performance figures that PHP-PM delivers with Symfony validate =
that approach IMO.


> On 13.04.2016, at 17:55, Lin Yo-An <cornelius.howl@gmail.com> wrote:
>=20
> Hi internals,
>=20
>=20
> The javascript engine V8 uses a strategy called "startup snapshot" to
> optimize app load time (see
> http://v8project.blogspot.tw/2015/09/custom-startup-snapshots.html for =
more
> details)
>=20
> The approach used by V8 creates a snapshot from heap, so the V8Context
> could be reused directly without re-running the bootstraping code.
>=20
> I think running javascript app in the browser is somehow like we run =
php
> script for each requests where the app bootstrapping code is required =
to be
> executed repeatedly for each request.
>=20
> Currently, our opcache extension can cache the byte codes, but the =
byte
> codes still need to be executed every time when bootstrapping an app, =
and
> which increases the overhead for each request.
>=20
> For example, a lot of applications use composer to initialize the =
class
> loader via the statement below:
>=20
>    require "vendor/autoload.php";
>=20
> The statement above produces thousands of byte code to run, which is =
to
> make an app ready. (If you use vld extension to show the opcodes)
>=20
> However, if we can support a simple syntax to describe what is doing
> "bootstrap", we are able to create a startup snapshot from it.
>=20
>=20
> The proposal here want to introduce some new syntax to optimize app =
load
> time though the below syntax:
>=20
>    bootstrap "vendor/autoload.php";  // caches the context after =
running
> this script.
>=20
> Or
>=20
>    bootstrap {
>           require "vendor/autoload.php";
>           // do something else for making app ready
>    };
>=20
> And of course, we might detect the bootstrap script automatically =
without
> creating new syntax and opcodes, but I think it's hard to do because =
PHP
> applications can be written by many ways...
>=20
>=20
> Questions
> =3D=3D=3D=3D=3D=3D=3D=3D
>=20
> I don't know if this approach is doable or not. Or maybe we can =
support
> this in a separated extension instead of changing the zend core?
>=20
> Do you guys think it's doable? would you like to share your idea for =
this?
>=20
>=20
>=20
>=20
>=20
>=20
> Best Regards,
>=20
> Yo-An Lin