Don't cache content of state events #929
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
onContentChanged() is necessary because EventTemplate<StateEvent> stores event content as a C++ structure after converting it from JSON; while not all content JSON changes may lead to changes in that structure, there's no way to tell. Alternatively, we could get rid of storing the converted structure entirely - conversion usually doesn't take long anyway, if it repeats even another couple of times that should be fiiine?.. In return, we get savings from not doing conversions in bulk while loading events from syncs and backpagination.
|
Instead, both current and previous content is now produced on the fly, on each content() and prevContent() call. This is obviously suboptimal in case of repeated content() calls but saves both time and space when most data from state events are not actually requested - which seems to be a common case, as clients rarely visualise each and every part of the state. When benchmarking on Quotest, and assuming the next commit (that optimises RoomMemberEvent, the most frequent state event of all) applied, the slowdown was about 2.5% and even that was within the deviation range.
KitsuneRal
force-pushed
the
kitsune/slimmer-state-events
branch
from
a073482 to
8f7e262
Compare
TobiasFella
approved these changes
Oct 11, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In most cases, the content of those events is not read, anyway - because not all events are actually displayed by clients. As 2f3be05 (the key commit in this PR) says, the slowdown in (slightly patched) Quotest - specifically, on a request of 1000 historical events - was about 2.5% and it was within the standard deviation. In the actual usage by client the difference is likely to be even less.
Why this change at all: while working on intentional mentions, I thought of introducing
RoomEvent::setMentions()(I haven't found that mentions only can be used on message events so I will implement them on the room event level - coming in a separate PR), which will necessarily change the content JSON of the event because that's where the mentions are put. This is where the first commit comes from, actually - first, I introduced the way to change the event content JSON so that inheriting event classes are notified about the change viaonContentChanged(). Then I figured that the only class of cases where such notification is needed atm seems to be state events because they store the deserialised content. So I tried to optimise this part away, and it seems things are not massively deteriorating.