Everything

php

Re: Proposal: Startup snapshot for optimizing app load time

php.internals

Lin Yo-An

10 years ago

On Tue, Apr 19, 2016 at 3:10 AM, François Laupretre <francois@php.net>
wrote:

>
> Le 13/04/2016 17:55, Lin Yo-An a écrit :
> You are mixing 2 related mechanisms here : code persistence and data
> persistence.
>
> Code persistence (reloading the same code again and again in each request)
> is achieved through the autoloader. Autoloading, compbined with opcache
> provides a very fast mechanism to retrieve class definitions. If you
> measure the time taken by your 'require "vendor/autoload.php"' stance, you
> should find it to be extremely fast (with opcache on, of course).
>

"vendor/autoload.php", in this example, is pretty simple, however in most
applications, there are bootstrap script for bootstrapping services (mongo
service, mysql service, sms service ... etc) and setting up some
configurations.

Data persistence is another question: the need here is to save and restore

> object instances. Several cache mechanisms exist for this, saving and
> restoring via serialize/unserialize. The problem with your 'bootstrap'
> approach (apart from the fact that it is not physically possible in PHP) is
> that you won't want to snapshot the *whole* environment, because you always
> want to keep at least some dynamic context. What you actually want to
> 'snapshot' is a set of well-defined object instances. So, the question,
> IMO, is to develop a mechanism faster than the current ones to store and
> retrieve object instances from memory

Yes!  not all global variables will be snapshotted, for now I think EG,
SPL_G (which saves the autoloader instances), and some object instances and
zval. Then these opcode could be skipped a lot. So this looks like
something on top of opcache.

--
Best Regards,

Yo-An Lin

Johannes Schlueter

10 years ago

On Tue, 2016-04-19 at 23:59 +0800, Lin Yo-An wrote:

>
> Yes!  not all global variables will be snapshotted, for now I think
> EG, SPL_G (which saves the autoloader instances), and some object
> instances and zval. Then these opcode could be skipped a lot. So this
> looks like something on top of opcache.

This calls for quite some trouble. On the internal level one has to mind
that we use raw pointers for most things and depend on the zend
allocator to clean up memory forcefully on request end. Tracking this
safely is quite some work..

Just think about the different memory areas touched by this code:

bootstrap.php:
<?php
class AutoLoader {
function load($class) {
static $count = 0;
eval("class $class { function __construct()  { \$this->c = ".(++$count).";}}");
}
}
$al = new AutoLoader();
spl_autoload_register([$al, 'load']);

$foo = new Foo();
$bar = new Bar();
?>

main.php
<?php
bootstrap 'bootsrap.php';
$baz = new Baz()
echo $foo->c.$bar->c.$baz->c;
?>




On the individual function level you have to be careful about
side-effects. What should happen if session_start() or srand(), just to
mention two very different functions with side-effects,are called from
the bootstrap code.


I believe this is a massive project which requires refactoring for all
internal data structure and review for internal functions to mark them
as bootstrap-safe, or not..

johannes