-
-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Perf] Buffer client>server events #16
Labels
Comments
ptaoussanis
changed the title
Optimization: buffer client>server events w/o callbacks
Optimization: buffer client>server events
Sep 21, 2014
ptaoussanis
added a commit
that referenced
this issue
Sep 21, 2014
ptaoussanis
added a commit
that referenced
this issue
Sep 22, 2014
tobias
pushed a commit
to tobias/sente
that referenced
this issue
Jan 29, 2015
ptaoussanis
changed the title
Optimization: buffer client>server events
[Perf] Buffer client>server events
Dec 10, 2015
ptaoussanis
added a commit
that referenced
this issue
Oct 26, 2016
Objectives: - [#276] Support easy+efficient generic un/pack caching. - In particular: support cache-friendly server->client event buffering. - [#16] Support client->server buffering with arb cbs. - Read+write performance. - Bandwidth efficiency. - Flexibility for possible future extensions/changes. - Human-readable on the wire (handy for debugging, etc.). - Lay groundwork for possible broadcast API fn. Downsides: - Would involve a breaking incompatibility with old clients.
ptaoussanis
added a commit
that referenced
this issue
Oct 26, 2016
Objectives: - [#276] Support easy+efficient generic un/pack caching. - In particular: support cache-friendly server->client event buffering. - [#16] Support client->server buffering with arb cbs. - Read+write performance. - Bandwidth efficiency. - Flexibility for possible future extensions/changes. - Human-readable on the wire (handy for debugging, etc.). - Lay groundwork for possible broadcast API fn. Downsides: - Would involve a breaking incompatibility with old clients.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is far less important than buffering for server>user events (which we now have), but it'd still be a big efficiency win - esp. for Ajax + for bandwidth minimization on mobiles.
It's even possible to offer this for events with callbacks if we're prepared to allow actual timeouts to vary by
[0,<max-buffer-window-size>]
ms.UPDATE: Have started some work for this on the
dev
branch. Shouldn't be hard to implement, just short on time atm.The text was updated successfully, but these errors were encountered: