perf(ext/websocket): efficient event kind serialization #18509
Conversation
Agreed, that probably causes V8 to deopt the function anyway |
| } | ||
| Some(Ok(Message::Ping(_))) => ( | ||
| MessageKind::Ping as u16, | ||
| StringOrBuffer::Buffer(vec![].into()), |
There was a problem hiding this comment.
Does it make sense to send these empty buffers? Could we replace them with undefined? That still wouldn't address the fact that this function is megamorphic and will get deoptimized by V8 every time data received is different than when the function got jitted (if it gets jitted at all)
There was a problem hiding this comment.
Idea to explore: store the received data on the Websocket struct, return only the number to JS and immediately call a sync op that either gets a buffer or a string (ie. two separate ops). That way we wouldn't make V8 deoptimize this function
There was a problem hiding this comment.
Does it make sense to send these empty buffers? Could we replace them with undefined?
Option<StringOrBuffer> makes it a little slow, since Ping and Pong are not frequent events i've left them as-is.
That still wouldn't address the fact that this function is megamorphic and will get deoptimized by V8 every time data received is different than when the function got jitted (if it gets jitted at all)
It won't get deoptimized everytime return value changes. AFAIK V8 can learn that this function returns either a AB or string back. It'll have JIT code prepared to handle that after a few calls.
This commit adds a new core API `opAsync2` to call an async op with atmost 2 arguments. Spread argument iterators has a pretty big perf hit when calling ops. | name | avg msg/sec/core | | --- | --- | | 1.32.1 | `127820.750000` | | #18506 | `140079.000000` | | #18506 + #18509 | `150104.250000` | | #18506 + #18509 + this | `157340.000000` |
Use u16 to represent the kind of event (0 - 6) & event code > 6 is treated as the close code. This way we can represent all events + the close code in a single JS number. This is safe because (as per RFC 6455) close code from 0-999 are reserved & not used. | name | avg msg/sec/core | | --- | --- | | deno_main | `127820.750000` | | deno #18506 | `140079.000000` | | deno #18506 + this | `150104.250000` |
This commit adds a new core API `opAsync2` to call an async op with atmost 2 arguments. Spread argument iterators has a pretty big perf hit when calling ops. | name | avg msg/sec/core | | --- | --- | | 1.32.1 | `127820.750000` | | #18506 | `140079.000000` | | #18506 + #18509 | `150104.250000` | | #18506 + #18509 + this | `157340.000000` |
Use u16 to represent the kind of event (0 - 6) & event code > 6 is treated as the close code. This way we can represent all events + the close code in a single JS number. This is safe because (as per RFC 6455) close code from 0-999 are reserved & not used.
127820.750000140079.000000150104.250000