4 ms·
Easy to say but often quite hard to do. Measuring, gathering, reporting, understanding what you’re seeing. These are often very complex and time consuming.
by andrewstuart 3y ago
Easy to say but often quite hard to do.
Measuring, gathering, reporting, understanding what you’re seeing. These are often very complex and time consuming.
- maccard 3y agoIf you can't measure it to prove that before and after are different, then you shouldn't optimise it. You run the risk of making things worse.
- IshKebab 3y agoSometimes things are obviously going to be slow even without measurement. For example not reserving a large vector. Or doing unbuffered IO.
- bluGill 3y agoI just measured a large vector and reserving makes minimal differnce for my case. Ammortized growth is a not slow. Ymmv of course which is why we measure.
- IshKebab 3y agoAt worst it makes no difference and at best it makes a big difference - maybe on an input that you didn't even measure!
- maccard 3y agoAt worst it will make it slower, and at best it will make it faster[0]. The only way to know is to measure with an input that's representative, and this case is exactly why you measure. [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...
- bluGill 3y agoWhich is why I measured with many different sizes. I know the fixed size version (the existing code), so I measured with 1 element, half the fixed sized version, the fixed sized version, and double the fixed size version. All with different amounts of reserved data elements. The fixed size version is faster, but not by enough to care about - at least in my case where the vector is created at startup and never changed after.
- maccard 3y agoI 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.