3 ms·

I originally thought this would be a story about query optimizers and their stupidity in the face of the banal. But it was infinitely better! I’ve never had th

I originally thought this would be a story about query optimizers and their stupidity in the face of the banal. But it was infinitely better! I’ve never had the chance to decrypt tls with wireshark so bookmarking for future reference. I’m a little surprised at the statement that ~10%+ performance on a transport protocol isn’t worth it. 1 million frames doesn’t seem like that much, and some workloads see these things scaled out as front end servers mostly managing stuff like websockets / JSON / utf nonsense. I’d argue if it’s deep in the kernel of execution and well abstracted in the higher level logic a cryptic bit fiddle with a comment, even perhaps with it’s more common equivalent in the comment, might be worth while. That leads me to the ultimate question: what was the Pokémon table used for?

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.
emmelaich 3y ago
I thought it might have to do with "order by random()" In a declarative language, random() would get executed once, so it'd be like "order by 4" (nod to xkcd)

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.

emmelaich 3y ago

I thought it might have to do with "order by random()" In a declarative language, random() would get executed once, so it'd be like "order by 4" (nod to xkcd)