RFC: 6.x - Change the default engine for `_cake_translations_` to `PhpEngine`.

[ADmad]

The TranslationsRegistry caches the full Translator instances. Switching from the current FileEngine which uses serialize()/unserialize() to PhpEngine which generates PHP code (which can be opcached) would give better performance gain.

[dereuromark]

so only _cake_translations_ for now, not _cake_model_ etc?
We should probably make a benchmark first on this.

[ADmad]

Ah right, CachedCollection also caches the TableSchema instances so probably using PhpEngine there too would help.

[dereuromark]

Thats the thing:
I thought about backporting it to cake5 via dereuromark/cakephp-shim#126

And no matter what benchmarks I run, I end up with no justification for it.
The write is much slower as we know, but the read also isnt really faster.

Would be interesting to know how to set up the env so that cache engine makes sense over classic caching engines we have.

[josbeir]

Thats the thing: I thought about backporting it to cake5 via dereuromark/cakephp-shim#126

And no matter what benchmarks I run, I end up with no justification for it. The write is much slower as we know, but the read also isnt really faster.

Would be interesting to know how to set up the env so that cache engine makes sense over classic caching engines we have.

@dereuromark write performance aside, read's should be very fast with opcache (but if your're benchmarking make sure to enable it in CLI + first write the file and do a new process to start the benchmark, you can't properly test this in the same process of when the file was written).

After that you should see very fast results.

[dereuromark]

Dah, you are right, the warming was counted in:

Best-case warmed read results, 5000 reads over 100 prewritten keys:

Payload	File us/op	PhpEngine us/op
translations	16.19	7.35
model_cache	15.90	7.49
nested_config	15.79	7.22
record_list	15.49	7.22

[josbeir]

seems to be a no-brainer, these results would even improve on larger apps

[dereuromark]

I would say we should NOT change the defaults here, especially since locally, this would make things slower.
We got constant cache invalidation every few seconds, so quite a bit more write necessity.

I think we should document this as opt-in path for deployment rather.

[markstory]

We got constant cache invalidation every few seconds, so quite a bit more write necessity.

Don't we have that problem with file caching today for local development though?

[dereuromark]

Yes, but write for PHP engine via that lib is super expensive
Up to 5 times more.
The advantage is only on read.

[josbeir]

Yes, but write for PHP engine via that lib is super expensive Up to 5 times more. The advantage is only on read.

documenting it works for me, i think your arguments are valid @dereuromark although it will probably not be noticeable during development in the end. But then again, there is no added benefit too :-)

php should work on pimping var_export :p

Going back to the original RFC subject here, defaulting it i18n is a good idea no?

[github-actions]

This issue is stale because it has been open for 120 days with no activity. Remove the stale label or comment or this will be closed in 15 days