🇳🇱
man I love this.. so when i did regular signale threaded optimization i got my algo from 16.7 minutes down to about 1 minute Now I moved to multithreading and it runs in about 5 seconds.
Never skip your optimizations people!
@ccc I dont entierly agree with this. In fact in my current situation that would be devastating if I took that advice.
What I would say is you shouldnt optimize something arbitrarily nor as a matter of fact before submitting a class. What you should be doing, however, is having profiling of the app as part of your CI suite so you can see the hot spots in your code and where time is being spent as you go. You should have the awareness of the final design your headed for if this will be a problem and do some combination of optimize or adjust your design to account for this. There is not absolute "when to optimize".
The reason for that is manifold, but here are some reasons waiting to the very end to optimize can be detrimental:
1) The poor performance of a component can slow down testing, and ultimately development to such an extent that it hinders development time significantly.
2) Generally projects are never truly finished. Any project worth its salt will be a living project and will likely always be improved upon iteratively
3) Architecture can be a limiting factor in performance. For example you can often optimize things significantly when done in catches where you couldn't do it when you operate on a per-element approach. If the architecture is designed to handle per-element access in the way its designed but not bulk access it may be impossible to optimize effectively later on. In extreme cases this may require the fundamental architecture to be rewritten and cost significant development time. By doing performance testing earlier on this would have been recognized and the architecture adapted before the project gets too far.
@freemo Oh, it's definitely something to take on a case-by-case basis. Optimisation is something you want to do before putting your project into actual production; and yes, you *do* want to ensure that your program passes all the tests *after* optimisation.
And yes, in some cases, the program might not even *run* unoptimised. Then you might *need* to optimise early, just in order to get anything done at all.
"Optimise late" is not, in any way, intended as a hard and fast rule. Rather, it's suggested as a useful bias - in many but not all situations. And if you can identify whether or not it's a good idea in any particular situation... then you already know enough to know when to ignore that suggested bias.
Took my findings to their manager and was invited for a two hour drive to meet with the manager and the san storage guys. I handed over the findings and was told the SAN was simply to busy for what we wanted. I looked at the manager and that was all we needed.
It must be hard to test such actions when hosting on a remote cloud.
@freemo Optimisation must, however, be done at the correct time.
And the correct time for optimisation is (usually) *after* you've done everything else you need to do with that program; because a lot of optimisations make it very tricky to *change* things later.