3 ms·

> I’m a little surprised at the statement that ~10%+ performance on a transport protocol isn’t worth it. Well, depending on which contrast we're making, the pe

by gmac 3y ago

> I’m a little surprised at the statement that ~10%+ performance on a transport protocol isn’t worth it. Well, depending on which contrast we're making, the performance difference on that one line is either 10ms (by which bit-twiddling is faster than Uint8Array.writeUint16BE) or 100ms (by which Uint8Array.writeUInt16BE is faster than DataView.setUint16) per million frames. I don't think that's going to be anything like 10% of the total CPU time per frame. Unless I've misunderstood your point here? > That leads me to the ultimate question: what was the Pokémon table used for? You know what, I just assumed it was a test data table, but I never asked!

fnordpiglet 3y ago
I guess my time doing low latency work and rust programming makes me see those numbers and want to shave that time off since it’s inside a protocol which you expect to be called millions of times in tight succession potentially dominating the machines performance on a front end node doing nothing but shuttling data. Definitely there will be a lot of other stuff contributing surrounding - but a march of a million miles starts with a single step ;-) certainly in a higher level business logic world I could see not squeezing every cpu cycle and optimizing for clarity of reading, but at very low levels of tight loops (at least in my world) time spent here is time not spent on stuff the developer cares about :-)
- norir 3y ago
  Yeah, I don't really understand why they didn't just comment out the high level function call (option 3) and inline option 4 below. Then they could have clarity and performance.
  - gmac 3y ago
    Sure, that was also an option. Feel free to submit another PR to the maintainers!
- tleb_ 3y ago
  What is being talked about is a single 16-bit write inside a byte buffer. The benchmark delta is 10ns per request (90ns for bit-twiddling vs 100ns for writeUInt16BE). 90ns/100ns is a lot for this kind of operation, but that comes from JS' handling of numbers and not a badly optimised routine.

by gmac 3y ago

fnordpiglet 3y ago

I guess my time doing low latency work and rust programming makes me see those numbers and want to shave that time off since it’s inside a protocol which you expect to be called millions of times in tight succession potentially dominating the machines performance on a front end node doing nothing but shuttling data. Definitely there will be a lot of other stuff contributing surrounding - but a march of a million miles starts with a single step ;-) certainly in a higher level business logic world I could see not squeezing every cpu cycle and optimizing for clarity of reading, but at very low levels of tight loops (at least in my world) time spent here is time not spent on stuff the developer cares about :-)

norir 3y ago
Yeah, I don't really understand why they didn't just comment out the high level function call (option 3) and inline option 4 below. Then they could have clarity and performance.
- gmac 3y ago
  Sure, that was also an option. Feel free to submit another PR to the maintainers!
tleb_ 3y ago
What is being talked about is a single 16-bit write inside a byte buffer. The benchmark delta is 10ns per request (90ns for bit-twiddling vs 100ns for writeUInt16BE). 90ns/100ns is a lot for this kind of operation, but that comes from JS' handling of numbers and not a badly optimised routine.