Excellent post showing how to correctly improve code w.r.t. performance using the scientific method: hypothesis, measuring the baseline, change, measuring effect with real tools, real code.
Thanks for sharing!
Thanks for sharing!
Meaning, yes, the OP got impressive performance improvements but the code is also completely unreadable and utilises unsafe code sections which could expose you to security problems/memory leaks/memory corruption. Not to mention they've recreated and will need to maintain an in-house version of the Dictionary class.
Their first optimisation (from Enumerator to List and Any() to Count()) are something every codebase could use. Most of their other optimisations make the code a maintenance minefield.
Plus programmers are expensive. Hardware is cheap. Why spent time on harder code to write that's also harder to maintain in the medium to long term when instead you could just throw money at hardware and call it a day? Just food for thought, not really a criticism in and of itself.
PS - Please don't take this post too seriously. I am not really being critical, just playing devil's advocate. I actually enjoyed the linked article a lot.
What it latency for a single request can't be improved with more cores?
What if your product is used by consumers who may have old hardware? or phones, or watches, or laptops and they want their battery to last?
What if you consistently practiced at making high performance code, maybe then it wouldn't seem "unreadable" to you any more?
What if Linq-like higher order functions weren't slow? https://github.com/jackmott/LinqFaster
What if slow software was common today because of modern attitudes, and I wasn't seeing any increase in stability or features to show for it?
Then re-design for map-reduce, and scale horizontally
> What it latency for a single request can't be improved with more cores?
Then look into pre-computing and caching
> What if your product is used by consumers who may have old hardware? or phones, or watches, or laptops and they want their battery to last?
I thought we were talking about server requests? If we are, then offload this work to the server
> What if you consistently practiced at making high performance code, maybe then it wouldn't seem "unreadable" to you any more?
But it's not all about you. Unless you're working on a pet project, or you have the credibility and reputation to be the final call on a significant open source project, you might get hit by a bus tomorrow. Or, if you do a really good job, your company will need you to be a force multiplier to teach a dozen others to try to imitate you. Even if you're a "10x" programmer.
And by the way, when you optimize code THIS much, any refactoring or tweaks to new features cause your optimizations to get tossed out, and you have to start over from scratch.
> What if Linq-like higher order functions weren't slow? https://github.com/jackmott/LinqFaster
https://github.com/jackmott/LinqFaster#limitations
> What if slow software was common today because of modern attitudes, and I wasn't seeing any increase in stability or features to show for it?
Except you are, and you don't even realize it. Optimizations like this blog post matter a LOT on client software. Be it apps, or websites - anything run on the client will need this kind of attention sometimes.
But this guy is writing server software. Micro-optimizing on the server side the way he is doing is silly.
Khm... What if you have millions of requests per second with tight latency requirements measured in milliseconds; and a bunch of business logic to fit into that. Such optimizations aren't so silly. There are different scenarios on both client and server sides.
It seems like most git guis are pretty commit-focused. I'm not sure of any way to do it in the command line (though it must be possible) but it would be nice to highlight a section of code in your IDE and have git give you a history of just those lines (or that function) as far back as you want to go.
I cannot believe that you are honestly saying a 2x increase to throughput in production is something you "shouldn't take seriously" because the code isn't as readable as it was before.
Programmers are expensive. Hardware is cheap. That doesn't justify completely throwing out the window any performance increasing changes just because a fresh college grad won't be able to understand what's going on within 10 minutes.
I've worked on large and old codebases for years. I've seen plenty of examples of where a "clever" programmer has optimised the heck out of a section of code, made it completely unmaintainable, and as a result forced a re-write (the resulting code, which was slower, was also easier to maintain and reason about).
"Production" is a meaningless rallying cry. Everything is production sooner or later. Not everything needs to be fast, although there are critical areas of a typical project that do. It is really a question of code quality relative to performance, unless performance itself is actually causing you problems. Typically these overeager performance fixes are done to code preemptively.
This is all fine for your pet and toy projects, go work on something enterprise grade. Big code means clean code. I'd take ten lines of clean easy to consume code over one "clever" line of genius.
The usual caveat of making code correct, readable and then fast in this order of course also applies :)
This is entirely a matter of scale. 1 dev can make faster software that runs on thousands of machines with far more ROI than the hours they spent. This is common in several industries.