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.
After our latest performance tests, it became clear that Express performs poorly for small messages.
But we already knew that, Express wasn't made to send small messages - no big surprise.
Well, based on our current per-key storage metrics, people are sending tons very small messages using Express. Unfortunately with messages this small, their experience will be exclusively worse than if they had just used a net message.
The performance tests highlighted another important thing: Express is only worse for messages that require 3 or fewer net messages.
This is interesting. If we look at both the usage metrics and the performance results, we find a cheap way to improve Express.
I don't necessarily want to make a pure-net data sender, but we could pretty easily cover the situation where a message could fit into a single net message.
That's what this PR does; it redirects small message payloads through the net library instead of the Express API, while still behaving the same way (calling receivers, respecting preDl receivers handling proofs, etc.).
I want to take this opportunity to refactor a few things and slim down the code, so the diff will be large but the functional changes will be few.
I also need to decide what to use as the
id
for these "small" messages in the callback chain. (some callbacks want the item ID). I don't want to introduce a regression, but I also don't want to write any worse code...