3 ms·
I stand by my point. There's a great stack overflow question [0] that shows a big pitfall of reserve. IO buffering is also not as clear cut. If you're running
by maccard 3y ago
I stand by my point. There's a great stack overflow question [0] that shows a big pitfall of reserve.
IO buffering is also not as clear cut. If you're running on a terminal, sure. But if you're outputting to a log file, or running in a CI environment where your stdout is being captured and redirected to a parent process, moving to buffered IO changes the semantics significantly. Imagine this code:
log("dangerous precondition hit, logging some state:" + state);
function_crashes_here()
With buffered IO, you very likely lose your log line.
[0] https://stackoverflow.com/questions/48535727/why-are-c-stl-vectors-1000x-slower-when-doing-many-reserves https://stackoverflow.com/questions/48535727/why-are-c-stl-v...
- gpderetta 3y agothat's why you to take a best-effort attempt at flushing your logs in your crash handler. You can't realistically measure everything. You start with a sensible design and implement the reasonable optimizations you learned by experience. Then measure and improve when and if you fail to hit your target.
- IshKebab 3y agoThat's nothing to do with performance. Profiling won't help you catch that issue.
- maccard 3y agoPerformance doesn't exist in a vacuum. The fastest way to optimise a loop is to remove all the code in it, but you're changing the program in order to do so. Adding/removing IO buffering absolutely _does_ have side effects. If someone is running `./app >> /dev/null 2>&1`, then mucking arouind with IO buffering is going to have little to no effect.
- IshKebab 3y agoOk but that is irrelevant to the discussion which was about whether profiling is absolutely necessary 100% of the time.