Cache backend should use the serializer service.

it would be better to use the serialization.phpserialize service that wraps these two functions.

Thanks for the effort. Why do you think so?

My assumption would be that you can swap out the serialization implementation with one of the faster alternatives?

@cburschka
Please document this in the issue summary, so its easier for others to understand.

Even though Drupal\Component\Serialization\PhpSerialize looks quite innocent, we still might want to check the performance impact of this modification.

Also: Why do we actually serialize here at all? It looks to me that the cache backend is responsible for serialization/deserialization in the first place.

Update: Please ignore that comment, I was under the impression, that we are discussing serialize/unserialize in page cache. Sorry for that.

Made a small update to the IS, I wanted to try to the patch but it no longer applies, so added the needs reroll tag.

I don't think we need any explicit test coverage for this, because it's indirectly tested sufficiently. I agree with @znerol though, this needs profiling tests to see if this makes usage slower.

The patch does look quite simple, so that's great.

Re-rolled.

Fixed test failure.

I tested this by running ab -n 200 -c 1 to a local drupal install (home page, a view with 5 pages, only page cache)

              min  mean[+/-sd] median   max
Total:        263  343  48.2    335     627
Total:        263  329  13.1    332     383

The first line is without the patch, the second with the patch. It looks like this is a decent improvement. We should probably do a check with xhprof as well but it looks like this patch does improve the request time.

It would be nice to see this on a real life website with a LOT of cache gets.
@borisson_ Page cache basically means you have just a few cache gets. It becomes more interesting if you would have way more cache gets on the page.

I tried to disable page cache and dynamic page cache and reproduced your test. Its hard to say but I think the result is still inside random fluctuation: https://blackfire.io/profiles/compare/a7abdb67-01b2-4f4e-8b9e-9a7f19ba30...
Maybe @berdir could make some profiling for their gigantic installations?

@dawehner, yes - having real-world profiling would be a lot better. However, both your tests and mine did find that there isn't a big change that we should worry about.

I like the patch, but isn't that a pretty hard BC break for the Cache\DatabaseBackend Interface?

Duplicate of #839444: Make serializer customizable for Cache\DatabaseBackend.