You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The enabled check for UUIDs is call on every creation of every UUID object. On setups with many content pages that thousands of roundtrips to the app instance can be avoided.
Adding a simple static cache here will vastly improve that.
It's a bit trickier as the app instance can be cloned with new options. In that case, calling Uuids::enabled() could return a value that doesn't match the config option anymore (which happens a lot in our unit tests). And I am a bit hesitant to unset the static property of Uuid from e.g. inside App::clone().
just my 2c... the call is executed very often and the clone probably not, right? i mean in a regular website installation. i would argue to handle the special case in the clone method.
In my 20k pages testsuite Uuids:: enabled will be called 25.7k times amounting to 6.5% of all execution time. This would be a huge performance boost for the core.
I am not arguing against it. Just trying to find a good sustainable way as the clone method isn't the only way a new app object with different config option could be introduced during the same request. Not super likely outside of the unit tests, but it still has to work for those scenarios as well.
Description
The enabled check for UUIDs is call on every creation of every UUID object. On setups with many content pages that thousands of roundtrips to the app instance can be avoided.
Adding a simple static cache here will vastly improve that.
current
proposed
kirby/src/Uuid/Uuids.php
Line 83 in a0e64e8
The text was updated successfully, but these errors were encountered: