3 ms·

Explaining the circumstances behind this particular optimization target would certainly have been more helpful; as a standalone exercise, reducing allocations d

Explaining the circumstances behind this particular optimization target would certainly have been more helpful; as a standalone exercise, reducing allocations does look rather useless. But the author presumably has some reason for focusing on allocations (and GC generations, though that never really comes up). Perhaps the subject code is causing excessive GC pauses in the larger program it is part of? If they're doing "real-time calculations" as part of financial services, I can see where adding latency for several seconds could be a bad thing.

dahart 8y ago
I agree, I totally buy that it's possible there's an unstated reason to worry about the sum of allocations over time. Though, in an article of this length and depth, not spending a sentence or two and stating that reason seems like an obvious omission. And a reason is given, so I don't know why there'd be another separate hidden reason: "Currently this import process has to take place outside of business hours because of the impact it has on memory usage." That statement is pretty confusing to me; if the high watermark is 16MB, there's no memory usage problem to begin with. And if saving 25% CPU time is enough to go from after hours to during business hours, it won't take much to push the jobs back to after hours, right? The hyperbole in the title & headlines combined with the vague issue of memory usage also leads me to believe this might be more about exposure for the blog post than fixing a problem. That's perfectly fine, but it's also okay to discuss and question what we're presented with, right? It all feels to me like optimizing to the wrong metric. If you really want a parser to go fast, then eliminate line buffered input and block read the thing. Then eliminate all other memory allocations and process the file in memory. That will increase the memory usage in this case substantially, but it will be much faster than the improved version v11 they ended up with.

dahart 8y ago

I agree, I totally buy that it's possible there's an unstated reason to worry about the sum of allocations over time. Though, in an article of this length and depth, not spending a sentence or two and stating that reason seems like an obvious omission. And a reason is given, so I don't know why there'd be another separate hidden reason: "Currently this import process has to take place outside of business hours because of the impact it has on memory usage." That statement is pretty confusing to me; if the high watermark is 16MB, there's no memory usage problem to begin with. And if saving 25% CPU time is enough to go from after hours to during business hours, it won't take much to push the jobs back to after hours, right? The hyperbole in the title & headlines combined with the vague issue of memory usage also leads me to believe this might be more about exposure for the blog post than fixing a problem. That's perfectly fine, but it's also okay to discuss and question what we're presented with, right? It all feels to me like optimizing to the wrong metric. If you really want a parser to go fast, then eliminate line buffered input and block read the thing. Then eliminate all other memory allocations and process the file in memory. That will increase the memory usage in this case substantially, but it will be much faster than the improved version v11 they ended up with.