In MDL-69707 we improved the redis session handler to not bother writing to the session if the session hasn't changed. In practice $USER->preference['_lastloaded'] is reset to now's timestamp on many page views which forces a session write and in most cases it is the only thing which has changed.

This is 15 year old code, but as far as I can understand _lastloaded is purely used to manage a static cache of how old the preferences are in memory, and this only matters for extremely long running processes - ie more than 2 minutes. I assume this was only intended to affect cron processes, and would also invalidate the cache on really long running pages which reloaded the preferences (which probably never happens). Every time preferences are actually needed the first time in a request it seems to always go back to the database, so this cache in the session seems redundant.

I think it is safe to move this variable into a static var and not inside the session, which will stop the constant session writing churn. There looks to be an edge case with the guest user which should store this in the session as it doesn't make sense to persist it in the database.

Additionally it might also make sense to refactor this to use MUC instead with the built in static cache. It might also make further sense to make this an application level instead of a session cache and keyed on the user id, rather than on the session id, so that all sessions have preferences in sync which would simplify things a lot and remove the need for the cache reset flags. It could have a cache expiry of say 10 hours to cover a typical work / study day.