I'd be thrilled to get some benchmarks on your scenarios.

https://gist.github.com/palex-fpt/82fc3deed09c2de2a9023080a9613ce3
largeObject - it is serialized. igbinary gives 2x bust over php serialize.
largeExportableObject - in var_export form it loads in 10x+ faster than serialized.

Instead of using native php serialization, this uses a marshaller that represents objects in plain static arrays. Unmarshalling these arrays is faster than unserializing the corresponding PHP strings (because it works with copy-on-write, while unserialize cannot.)

There is native support to var_export serialization:
http://php.net/manual/en/language.oop5.magic.php#object.set-state

Classes implemented this method should be able to restore from var_export-ed form.

There is native support to var_export serialization:

I think I can make the marshaller handle these. Let me give it a try.
Thanks for the bench also.

Here we are, the generated PHP files now use__set_state when possible.

Now green, comments addressed@stof, thanks.

Is any chance to have extension point to switch between php serialization and igbinary?
IMHO it would be good to have method where inherited class would be able override mapping between variable type and used marshaling method.

I managed to remove the unmarshaller part of this PR, and leverage__set_state instead.
This allows generating ultra performant code that needs no userland logic but only minimal PHP code.
In order to not instantiate all objects in its pool forPhpArray* adapters, and in order to skip the wrapping logic aroundinclude inPhpFiles* adapters, this code is wrapped in closures that are called on demand.

Combined with#27549, this results in a significantly faster value loader that benefits from OPcache shared memory as much as possible.

Is any chance to have extension point to switch between php serialization and igbinary?

What would be the benefit?serialize() is now used only in specific situations: when a structure contains internal references or when objects implementingSerializable are found. We could useigbinary() instead in these situations, but I would hardcode it to make things simpler. WDYT?

I wrote bench for measure object load times:https://gist.github.com/palex-fpt/121a24e53ded4a0f6bb72307fc823a50

TBH I would like to have PhpFilesTrait looks like:

// doSave()...            $ok = $this->write($file, '<?php return '.var_export(array($lifetime, $this->serialize($value)), true).';') && $ok;...// doFetch()...                    list($expiresAt, $values[$id]) = $this->unserialize(include $file);

This way we would move all responsibility to prepare 'the best' serialization form to serializer. Leaving PhpFilesTrait with file handling and using opcache.

I wrote bench for measure object load times:https://gist.github.com/palex-fpt/121a24e53ded4a0f6bb72307fc823a50

I was surprised by the speed ofvar_export so I looked better at it: the script uses var_export on already var_exported data, which PHP just has to load a simple string. That's not what you wanted to bench or course. When removing this double var_export, you get a fatal errorCall to undefined method stdClass::__set_state(), which is what I would have expected.

That leaves us with the marshaller as the best solution, great :)

Oops. My mistake. I updated gist. Igbinary looks like the winner. And it uses three times lesser space.

I tested with range of options. When data use a lot of object instances - it looses to igbinary. When data is composition of scalars - PhpMarshaller is winner. It'll be good have option to choose marshaller based on used data.

Igbinary looks like the winner. And it uses three times lesser space.

actually, it doesn't to me, because this is missing a very important property of the native php format: it leverages php shared memory. This means the php format uses zero extra memory past the first request. This also means zero memory transfer to access the data: you just manipulate pointers to shared memory under the hood.

There is a pathological test case that illustrates this:
php -dopcache.enable_cli=1 -dapc.enable_cli=1 test.php

error_reporting(-1);require'vendor/autoload.php';useSymfony\Component\Cache\Adapterasp;$cache =newp\PhpFilesAdapter();//$cache = new p\ApcuAdapter();$mem =memory_get_usage();$start =microtime(true);$i =10000;$values =array();while (--$i) {$values[] =$cache->get('foo',function ($item) {returnstr_repeat('-',10000);    });}echo1000*(microtime(true) -$start),"ms\n";echomemory_get_peak_usage() -$mem,"\n";

Takes 23ms + 123MB with Apcu (~mimics serialize/igbinary)
And 13ms + 555KB with native PHP.

PR now tested and green. Ready.

@palex-fpt now that this is faster than igbinary there is no reason anymore to allow any sort of extensibility here. On the contrary, I prefer this to be closed and remain internal details.

Do you have benchmarks?

tree depth 3, values: 50, iterations: 1000

With my typical scenario (one access to key-value pair per request) it does not looks good.
As I tested against your branch - it's hard to configure cache with igbinary here.

https://gist.github.com/palex-fpt/913fbe1b1def170c2785d3e26ce4f77e

it looks like first call to 'get' method is performed against empty opcache. 'set' method should populate opcache.

To me, this looks really good: storeand 1st get are is slow calls, that's expected as caches have much higher read-rate than write-rate. For PhpFileAdapter, that's even more the case because since this leverages opcache, it should be used in append-only scenarios. The reason is that opcache itself is append-only: it never frees memory until its buffer is full, in which case it just empties it and starts over. Obviously, this should never happen. This means that if one plans to store data that can expire/be deleted at some non-zero rate, this is not something we should encourage/support.
Seehttp://blog.jpauli.tech/2015/03/05/opcache.html for details about this.
The best use case for PhpFileAdapter is for system caches, and this is where we use it. In this scenario, data is append-only, which means per-request locality is also a great optimization with no downside.
With this reasoning, if you want to use igbinary, then this should be done with FilesystemAdapter, which your other PR will allow. The reason is that if your data is append-only then there is no better backend than PhpFileAdapter, and if not, then opcache is not a good fit, unless you're ok with emptying its memory periodically by design, which is a scenario I wouldn't support (so that I have no incentive to add code to handle igbinary there.)

'set' method should populate opcache.

done

The reason is that opcache itself is append-only: it never frees memory until its buffer is full, in which case it just empty it and starts over. Obviously, this should never happen. This means that if one plans to store data that can expire/be deleted at some non-zero rate, this is not something we should encourage/support.

Opcache is fastest available cache with node locality. We reset opcache on node on 'switch to new build' deployment. It happens at least once per day. Any frequently accessed data that has change rate lower than deployment rate is perfect candidate to be stored in opcache. Limit opcache to append only is forcing to use slower caches or to do unnecessary redeployment on data change. Ex. does use-case that allows to change title of site directory (which happens once per year or never) should forbid use opcache for site directory attributes?

Caching retrieved data adds some burden to backend services. Service that enumerates over large portion of opcached objects can go oom. But it can be handled with $cache->reset() on each iteration.

I'm ok with current PR. It is big step in performance from opcaching serialized strings. Further improvements can be done in separate PRs.

Great, PR is ready then :)
ping @symfony/deciders

Thank you@nicolas-grekas.

since you gave me the push to work on this, and are pursuing a similar goal in#27484. I'd be thrilled to get some benchmarks on your scenarios.

As it does not support objects with __set_sate and cannot be overridden to made that support I can not benchmark it against my configuration. I hope it can be done later.