4 ms·

Sorry, but you're just wrong on this. Here's an example of parsing a string like the one in there: http://pastie.org/3429643 http://pastie.org/3429643 It par

by wheels 15y ago

Sorry, but you're just wrong on this. Here's an example of parsing a string like the one in there: http://pastie.org/3429643 http://pastie.org/3429643 It parses that string and reads it into a struct at a rate of about 3 million per second on a single core on my Macbook Pro. That means for your example there of 850 machines in a cluster, we're talking about roughly a quarter of a millisecond of one core of CPU time. Even if that's off by an order of magnitude, it doesn't matter. THERE IS ABSOLUTELY NO REASON TO OPTIMIZE THIS CASE The enemy of optimization is hard to maintain code, not small inefficiencies. Using text in this case makes the wire protocol easier to debug and generally easier to maintain for forward compatibility. Need to add an extra argument? It'll be both self-documenting and backwards compatible, instead of some versioned mess of bitflags. Could I be wrong? Sure. There's an easy way to prove such: show me the profiler output. Your eagerness for micro-optimizations significantly hints at inexperience.

moe 15y ago
The enemy of optimization is hard to maintain code Then why add string serialization to something that doesn't remotely need it? Using text in this case makes the wire protocol easier to debug and generally easier to maintain for forward compatibility. If anything the use an unspecified string format makes debugging potentially harder here (UDP truncation...).
peterwwillis 15y ago
Assuming that it'd perform that way in the real world, you are right that my solution would have no significant performance increase over the sscanf you use. But I don't totally agree with some of your supporting arguments. The wire protocol you're talking about is a heartbeat protocol. This doesn't need to be human-readable because there is no input from a human, nor is it intended for a human to read. Debugging it would be as complicated as a "printf". Oh the horror. We wouldn't want to add debugging to our application - better make people read the raw data with a packet sniffer (which you can't run unless you have root, so good luck getting your application debugged quickly, developers). Adding an extra argument would require appending an extra field and incrementing the version. Oh noes the mess! Since both solutions are versioned, forward compatibility is just updating code in the server, and if you're going to change things you have to update code anyway, so this doesn't sound like a good reason to oppose it. Realistically, will more than a handful of shops have a big enough cluster for any of this to matter? No. But even your example of using sscanf is faster than Apache's code (http://pastie.org/3430085 http://pastie.org/3430085) while being 100% compatible with the rest of the code, and still goes to show that doing it right the first time is better than just slapping something together and waiting until you have to optimize. So do we need to use an unreadable, simpler solution? No. But it would work just as well as anything else and take just as much time to write - if not less.

by wheels 15y ago

moe 15y ago

The enemy of optimization is hard to maintain code Then why add string serialization to something that doesn't remotely need it? Using text in this case makes the wire protocol easier to debug and generally easier to maintain for forward compatibility. If anything the use an unspecified string format makes debugging potentially harder here (UDP truncation...).

peterwwillis 15y ago

Assuming that it'd perform that way in the real world, you are right that my solution would have no significant performance increase over the sscanf you use. But I don't totally agree with some of your supporting arguments. The wire protocol you're talking about is a heartbeat protocol. This doesn't need to be human-readable because there is no input from a human, nor is it intended for a human to read. Debugging it would be as complicated as a "printf". Oh the horror. We wouldn't want to add debugging to our application - better make people read the raw data with a packet sniffer (which you can't run unless you have root, so good luck getting your application debugged quickly, developers). Adding an extra argument would require appending an extra field and incrementing the version. Oh noes the mess! Since both solutions are versioned, forward compatibility is just updating code in the server, and if you're going to change things you have to update code anyway, so this doesn't sound like a good reason to oppose it. Realistically, will more than a handful of shops have a big enough cluster for any of this to matter? No. But even your example of using sscanf is faster than Apache's code (http://pastie.org/3430085 http://pastie.org/3430085) while being 100% compatible with the rest of the code, and still goes to show that doing it right the first time is better than just slapping something together and waiting until you have to optimize. So do we need to use an unreadable, simpler solution? No. But it would work just as well as anything else and take just as much time to write - if not less.