Google Can’t Spell, pt 2

It occured to me that if you were trying to remove the Connection header from in the middle of a char * buffer, the absolute fastest way to do it would be to use strstr() to get a pointer to it, then do a byte swap to change the token from “Connection” to “Cneonction”. If you choose to optimize for CPU cycles and not bandwidth, that’s a valid optimization.

The question is, who would be motivated to optimize like that? A content provider pays for their bandwidth. If I caught one of my developers pulling a trick like that, I’d walk over to his desk and wack him up side the head with the 2×4 Of Justice. CPU cycles (especially the 20,000 or so it would take to excise the string correcetly) are cheap compared to bandwidth. I suppose, in fairness, I’d have to make a spreadsheet proving my point before I won the right to whack the developer. But my gut instinct is so strong on this, I’d probably at least shoot them with a Nerf gun before I went to do the spreadsheet.

In a tightly constrained device, like a piece of network hardware where rewrites are happening in a VLSI at wire speed, this would be exactly the right way to implement the task “remove the Connection header while proxying an HTTP request”.

What an interesting example of an engineering tradeoff.

Or it could be that someone typo’d it. But I simply refuse to believe that.

One thought on “Google Can’t Spell, pt 2

Leave a Reply