3 ms·

Why not use a trie?

by verroq 13y ago

Why not use a trie?

kevingadd 13y ago
Kind of beside the point, really - this kind of micro-optimization doesn't actually improve performance to the extent you want, especially when you consider the downsides. You can improve HTTP throughput far more dramatically with higher-level optimizations, like moving request parsing into the kernel or otherwise doing things that address larger bottlenecks involved in getting HTTP requests from the network card. The Windows version of Node performs a lot better if you have it use Microsoft's kernel mode HTTP interfaces than if you use the crazy micro-optimized HTTP support in Node that is responsible for this bug. Ultimately, the prologue in a HTTP request - 'HTTP/1.1 GET' or whatever - is a tiny string of bytes and parsing it, even using the most slow language on the planet, really isn't that expensive. Optimizing that tiny bit of work isn't going to produce enormous gains. Mostly just an ill-advised attempt at being clever.
- MichaelGG 13y ago
  Having written a high performance (1Gbps+ on 2nd gen i7, loopback) speed SIP packet capture/parser, I'll just disagree that such optimization against a text based protocol is not always a waste of time or an attempt at being clever. Doing things like comparing strings against 4 or 8 byte integers can show remarkable improvement, especially for the common methods. HTTP (and SIP) have idiotically complex grammars for no reason other than the authors getting all clever on us because it's a "text based" format. I'd actually be shocked to find that HTTP is actually properly implemented in most cases (fully handling comments and line folding, for example). And then, even if you do implement it properly, you have to worry about other software interpreting it differently. So Proxy A determines a request is allowed and appends a header, but Server B reads the request in a different way and violates policy.

3 ms·

Why not use a trie?

by verroq 13y ago

Why not use a trie?

kevingadd 13y ago
Kind of beside the point, really - this kind of micro-optimization doesn't actually improve performance to the extent you want, especially when you consider the downsides. You can improve HTTP throughput far more dramatically with higher-level optimizations, like moving request parsing into the kernel or otherwise doing things that address larger bottlenecks involved in getting HTTP requests from the network card. The Windows version of Node performs a lot better if you have it use Microsoft's kernel mode HTTP interfaces than if you use the crazy micro-optimized HTTP support in Node that is responsible for this bug. Ultimately, the prologue in a HTTP request - 'HTTP/1.1 GET' or whatever - is a tiny string of bytes and parsing it, even using the most slow language on the planet, really isn't that expensive. Optimizing that tiny bit of work isn't going to produce enormous gains. Mostly just an ill-advised attempt at being clever.
- MichaelGG 13y ago
  Having written a high performance (1Gbps+ on 2nd gen i7, loopback) speed SIP packet capture/parser, I'll just disagree that such optimization against a text based protocol is not always a waste of time or an attempt at being clever. Doing things like comparing strings against 4 or 8 byte integers can show remarkable improvement, especially for the common methods. HTTP (and SIP) have idiotically complex grammars for no reason other than the authors getting all clever on us because it's a "text based" format. I'd actually be shocked to find that HTTP is actually properly implemented in most cases (fully handling comments and line folding, for example). And then, even if you do implement it properly, you have to worry about other software interpreting it differently. So Proxy A determines a request is allowed and appends a header, but Server B reads the request in a different way and violates policy.