Depending on the OPCache configuration, the cache can persist when the file is modified.
You may have to invalidate the cache with opcache_invalidate when the file is written.

Thanks for the advice. I've added calls to opcache_invalidate and apc_compile_file/apc_delete_file when those functions exists.

I had some problems with HHVM due to facebook/hhvm#4797 . On HHVM once php file is included during the request it won't be reloaded no matter what (in this particular request).

To avoid this when on HHVM I'm using file modification time to save cache item version number that I increment on save. It's also kept in file contents. When this numbers are different (checked using filemtime andinclude), I fallback to file_get_contents to fetch fresh data. The main drawback is that I can't delete cache items for HHVM, and I save empty expired value instead. Still, this cache is intended only for data that very rarely changes, so I don't think it matters.

I am not sure if this is a good idea actually. If I understand the code correctly, users of this adapter will have to be extra carefully to not cache arbitrary data as they will otherwise be executed when the cache is loaded which could make applications prone to code injection.

Actually, no, all data can be safely used with this adapter.

I just did a quick search and symfony already does similar thing for dumping translations:

Anyway, here is how this works in this adapter: the data gets exported using var_export and serialize. PHP docs state that var_export Outputs or returns a parsable string representation of a variable. So doing var_export on a serialized string will always result in a string that eval'd will evaluate to the serialized string.

For instance, let's take this nasty string:

$data = '"\'; echo \'a\';"' . PHP_EOL . "\0" . '\n\r';

The cache adapter will create this file:

<?php return unserialize('s:21:""\'; echo \'a\';"
' . "\0" . '\\n\\r";');

As you can see, it can handle everything fine, including null bytes, new lines and stuff.

Of course it works just as fine for arrays, objects etc., for example this:

$data = new \DateTime();

Generates:

<?php return unserialize('O:8:"DateTime":3:{s:4:"date";s:26:"2016-05-23 08:59:28.000000";s:13:"timezone_type";i:3;s:8:"timezone";s:3:"UTC";}');

This is interesting and would need to be benched against other approaches (#18823 esp.)

Yep, append-only for hhvm and native PHP: given the way opcache works (see http://jpauli.github.io/2015/03/05/opcache.html#understanding-the-opcache-memory-consumption), doing rewrites creates wasted memory, which we shouldn't. If one want rewrites, one should use another adapter IMHO.

OK, I can modify it. Should it sent an exception if data is already there? Should it also sent exception when lifetime is not infinite?

I think clear method should still be supported, just to make clear-cache and such work, right?

It should return false: PSR-6 doesn't allow exceptions for error reporting.
For clear cache, you'd need a strategy the might look like #18716 (we renamed nonce to version in a recent PR)

I made the adapter append-only.

I did a quick test to compare my adapter with OpCacheAdapter from other PR.

For my test I disabled revalidating opcache entirely (with revalidation enabled PhpFilesAdapter gets slower). I saved some values, each of them consisting of an array with 100 strings, 50 characters length each. I did my tests for PHP 7.0.6 on windows (with SSD, but that shouldn't matter for opcache).

Here's saving 5000 values, then read randomly 10000 times:

 Symfony\Component\Cache\Adapter\FilesystemAdapter: 6.8619,   88 megabytes peak memory usage
   Symfony\Component\Cache\Adapter\PhpFilesAdapter: 8.4227,   88 megabytes peak memory usage
    Symfony\Component\Cache\Adapter\OpCacheAdapter: 2.0824,  286 megabytes peak memory usage

For next tests I was reloading it until the response time settled down:

Here's results for 10 values read randomly 10000 times:

 Symfony\Component\Cache\Adapter\FilesystemAdapter: 0.8210
   Symfony\Component\Cache\Adapter\PhpFilesAdapter: 0.1625
    Symfony\Component\Cache\Adapter\OpCacheAdapter: 0.0115

Here's results for 5000 values read randomly 10000 times:

 Symfony\Component\Cache\Adapter\FilesystemAdapter: 1.7495
   Symfony\Component\Cache\Adapter\PhpFilesAdapter: 0.1820
    Symfony\Component\Cache\Adapter\OpCacheAdapter: 0.0125

OpCacheAdapter is slightly faster, but requires saving everything at once during initialization (no appends, regular save not supported).

Interesting. Can you please add apcu to the tested adapters, try on php 5.5&5.6, and/or share the test script?

Here are results for php 7 including apcu (I've changed saving test a bit to better show the difference in required memory):

Storing 5000 items and fetching them randomly 10000 times (no warmup):

 Symfony\Component\Cache\Adapter\FilesystemAdapter: 7.4497,    2 megabytes
   Symfony\Component\Cache\Adapter\PhpFilesAdapter: 1.5632,    2 megabytes
    Symfony\Component\Cache\Adapter\OpCacheAdapter: 1.7042,  286 megabytes
       Symfony\Component\Cache\Adapter\ApcuAdapter: 0.2520,    2 megabytes

Warmup....................

Fetching randomly 5000 items 10000 times (after warmup):

 Symfony\Component\Cache\Adapter\FilesystemAdapter: 1.4061,    2 megabytes
   Symfony\Component\Cache\Adapter\PhpFilesAdapter: 0.1710,    2 megabytes
    Symfony\Component\Cache\Adapter\OpCacheAdapter: 0.0140,    2 megabytes
       Symfony\Component\Cache\Adapter\ApcuAdapter: 0.1180,    2 megabytes

Storing 10 items and fetching them randomly 10000 times (no warmup):

 Symfony\Component\Cache\Adapter\FilesystemAdapter: 0.7901,    2 megabytes
   Symfony\Component\Cache\Adapter\PhpFilesAdapter: 0.1640,    2 megabytes
    Symfony\Component\Cache\Adapter\OpCacheAdapter: 0.0200,    2 megabytes
       Symfony\Component\Cache\Adapter\ApcuAdapter: 0.1150,    2 megabytes

Warmup....................

Fetching randomly 10 items 10000 times (after warmup):

 Symfony\Component\Cache\Adapter\FilesystemAdapter: 0.7881,    2 megabytes
   Symfony\Component\Cache\Adapter\PhpFilesAdapter: 0.1610,    2 megabytes
    Symfony\Component\Cache\Adapter\OpCacheAdapter: 0.0130,    2 megabytes
       Symfony\Component\Cache\Adapter\ApcuAdapter: 0.1130,    2 megabytes

I can try with different php versions later this week. Here are files I've tested with:
PHP file on server: https://gist.github.com/trakos/2395d896eb7ad51cac05c22d169b5ef4
.sh script fetching data with curl: https://gist.github.com/trakos/a5dd8482ff8239eb51d2d5f1ec39a4f4

As for settings, I've disabled opcache verification and increased memory for both apcu and opcache.

Looks promising, I think we could provide this adapter as an alternative to the apcu adapter.
I reworked the patch here: master...nicolas-grekas:cache-php-files
WDYT about it?

Thanks for clearing the code out.
You've dropped hhvm support - do you think it's not worth it?
Also, you're leaving it to user to not overwrite existing values, right?

You've dropped hhvm support - do you think it's not worth it?

it's intentional, because per your benchs, hhvm should use apc for about the same perf benefit

you're leaving it to user to not overwrite existing values

good catch, I'm going to fix that

you're leaving it to user to not overwrite existing values

Hum in fact I'm not sure I understand what you mean? The user can still overwrite values safely, isn't it?
If you mean append-only vs rewrite support, then it a yes, it's now up to the user to use the adapter in append mostly scenarios. More flexible imho, less error prone...

If I read this right, deleting key returns true, but does not call opcache_invalidate, so depending on settings it might mean value will still be returned on fetch. Do I understand this correctly?

I though the same, then I tested the real behavior, and deleted files are always taken into account (include fails) whatever the ini settings.

Patch integrated into #18823
Thank you @trakos @ttrakos