We need to be careful here the ability to read an existing cache will depend on the igbinary availability (think cache warming on a different machine than the one where it is installed).

I agree with Fabien. Using "igbinary" automatically when it's available on the server feels too magic for Symfony. It'd be better to add a config option to enable this feature explicitly.

@javiereguiluz @fabpot 👍
Just giving my 2 cents here
Moving to php7 has been painful for me as this assumes that, if you have igbinary installed, means you wanna use it (it came together with the php redis extension, not really a choice)
Unfortunately it wasn't available in PHP7 back then - or just wasn't stable, so this caused massive headaches.

I think it's possible to have autoadaptative behavior.
Yet, igbinary is one desirable enhancement, but compressing could also be another one (a native feat of the memcached extension btw.)
This means to me we'd ideally need a way to define a pluggable "serializer", that would have consistent behavior, and be able to handle the format (ie native or igbinary) + compression + whatever.
But this is a significant thing to achieve, and yet nobody complained - so the priority is not very high to me.
Therefore, I'm closing this issue. If anyone wants to take over, with the approach I described or any other one, please do :)

I have pool of large generated object trees (over 1k trees). Each request uses only one tree from the pool, so using opcache is memory inefficient and using memcache/redis would increase network load. I using file-based cache with igbinary serialization. In attempt to migrate to Symfony's Cache component I finds it hard to extend Symfony's implementations to replace serialization parts.
Are any plans to add serialization extension points to cache implementations?

There are no plans, but there could be PRs :)

I'm going to add MarshallerInterface.
Proof of concept: https://github.com/palex-fpt/symfony/commits/cache-marshaller

I'd call it SerializeInterface I think, it would have the least surprise effect IMHO. But looks good already :)

I renamed it to SerializerInterface and added some tests. Also I did heavy refactoring on opcache related caches.
I think opcache serializer should store data in serialized strings as few as possible to reduce deserialization performance hits on cache reads.
There is some friction between opcache caches (PhpArrayAdapter, PhpArrayCache) and SerializationInterface contract. Caches does not call SerializationInterface::unserialize on cache hits due to fact that deserialization is part of include file directive. And it is performed in cache classes.

If that could make your work easier, not all adapters should have a configurable serializer IMHO. The opcache ones don't need to especially.

I'm done with refactoring. Should I submit it with new feature PR?

Yes please

#27484