3 ms·
Yeah. We had an in house report generator that was epicly slow (about 7 minutes to gen a single report) We frequently have strange issue come in cause fucking
by wredue 3y ago
Yeah. We had an in house report generator that was epicly slow (about 7 minutes to gen a single report)
We frequently have strange issue come in cause fucking vendors can’t stop making changes, then saying “nobody changed anything that would cause that”!
Anyway. I told my boss I’m going to spend a day optimizing this, and got back “we had people try, it’s not really a valuable use of time”.
Long story short, I know that processing 10,000 lines of data should absolutely not take 7 minutes and now it doesn’t. Now we can run our entire day in 30 seconds. No threads. No async. Half a day of optimization.
I think part of the problem with optimization today is that people are completely clueless about how fast computers are, and thus stay happy with being slow just as a matter of ignorance. The FP community pushing that all optimization is premature optimization doesn’t help either.
- chriswarbo 3y agoUrgh, reminds me of a production error that was caused by a job running on a timer, assuming that some other job would have finished by then. That lead to two obvious questions: - Why is it on a timer, instead of being triggered when the first job was done? - Why was that first job taking over an hour to process XML data? Turns out the second one was accidentally-quadratic, since it was parsing a whole document to process its first record; then re-parsing the whole document to process its second record; etc. and this made it very slow when the XML was reaching several hundred MB. Unfortunately, the solution we went with was to set the timer to run 20 minutes later...