Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92250 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 7957 invoked from network); 13 Apr 2016 16:32:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 13 Apr 2016 16:32:58 -0000 Authentication-Results: pb1.pair.com smtp.mail=ocramius@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ocramius@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender) X-PHP-List-Original-Sender: ocramius@gmail.com X-Host-Fingerprint: 209.85.215.42 mail-lf0-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:35059] helo=mail-lf0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4B/12-26321-8B47E075 for ; Wed, 13 Apr 2016 12:32:57 -0400 Received: by mail-lf0-f42.google.com with SMTP id c126so77461590lfb.2 for ; Wed, 13 Apr 2016 09:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ECZf1gbI7yYZ/vS6GAcSr+G2/vfQ8ViaKTNYN5ut8wA=; b=szndmNhkJT+hRzkEF/newUt96iS+pr+8IZ5++KRCGHDpA365WBopHpnoENqfXhDG9r 50zXZlCsMa10WP0gCCS0cWwAgyjmk5i41WFNbnH3xSfdcpP+cN2wgciW9avrqxKCBR5B wPoonzz4MyLIawFoS6yYyLJzt7GjrUcS3u1bezaJmRfDBUEef+f14BaR6lkFVNJxNdQI /UbU20giUswkmaYA8dH8+t7vt05fIMi2Ji1JGhPPJPwawOFE1cOaW0XG1GfTT9AwKd8C 0LeGBbxloSRkUoo0uGcvGd58JpzpIDM6B/8BDvSkRhMUmtqIMUXR4ciiN1G/PUM7cbok VL/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ECZf1gbI7yYZ/vS6GAcSr+G2/vfQ8ViaKTNYN5ut8wA=; b=dZK1i8O4+NM15XGpDmXN+iZYsbZ6Zd0QBVpePH80Ku1YDt9dumMEKh0ss9D1wL71tV efck3Gq71u5Thcu4f8761wo+OMd4v+2xJDGYllqH0qmlhT6pHGVpLIf2wW+roN7SUIlG QZ+zZWbsq/VkNr2Cp5nvIdbK/McIlUG9gkc7c2CBVzEfc2xMPeNUh0iDm3+kqOQ0YW5B w3E9zj2KwkjWE6LNB2xHQMsqYLhzUv3Wqdn1GrfdOo8Q53ndBM8Jcnua6GL/xpeyzh1p 4J5Wt6Rmjm59baf13QDirjHmQxVtWGal1nSbND4Q9GnCmQRlTqVspk/Wjg1LTM2rDjAU gWDg== X-Gm-Message-State: AOPr4FWdSBgVmBwfNTcLcKVkhf+v60CZshZ4OiQebghqBdc9K6nyRD+BeKT67rVSal1ar18eIseMlBvSAgqAWw== X-Received: by 10.25.154.193 with SMTP id c184mr4618253lfe.69.1460565173466; Wed, 13 Apr 2016 09:32:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.126.67 with HTTP; Wed, 13 Apr 2016 09:32:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Apr 2016 18:32:33 +0200 Message-ID: To: Lin Yo-An Cc: "internals@lists.php.net" Content-Type: multipart/alternative; boundary=001a114022c655ff32053060542c Subject: Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time From: ocramius@gmail.com (Marco Pivetta) --001a114022c655ff32053060542c Content-Type: text/plain; charset=UTF-8 While this seems interesting, how would it address storing any context information of extension? The code above (in your examples) only stores information about the autoload stack, but anything that would rely on any extension (core or pecl or custom) would have to serialize information that is possibly not even available in userland. Any clue on that? Would it be acceptable to have it just fail/fatal? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On 13 April 2016 at 17:55, Lin Yo-An wrote: > Hi internals, > > > 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) > > The approach used by V8 creates a snapshot from heap, so the V8Context > could be reused directly without re-running the bootstraping code. > > 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. > > 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. > > For example, a lot of applications use composer to initialize the class > loader via the statement below: > > require "vendor/autoload.php"; > > 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) > > However, if we can support a simple syntax to describe what is doing > "bootstrap", we are able to create a startup snapshot from it. > > > The proposal here want to introduce some new syntax to optimize app load > time though the below syntax: > > bootstrap "vendor/autoload.php"; // caches the context after running > this script. > > Or > > bootstrap { > require "vendor/autoload.php"; > // do something else for making app ready > }; > > 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... > > > Questions > ======== > > 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? > > Do you guys think it's doable? would you like to share your idea for this? > > > > > > > Best Regards, > > Yo-An Lin > --001a114022c655ff32053060542c--