Why is X slow?

Blazing fast

If you program in the JavaScript world, then you're probably really familiar (and maybe sick of) seeing packages say "blazing fast". At some point, we developers decided that we wanted to use dynamic languages like Ruby, Python, PHP, JS, etc... but we were still behind in speed world when compared to compiled languages.

This point started becoming the obsession of many devs. You started seeing a project come up, then another project that did the exact same thing, but it was "faster". In the ruby world we saw this with the faker gem and the ffaker gem which stood for "faster faker". In the JavaScript world, we saw this with Node and IOjs... a fork of node that was being designed to be faster (among other political reasons).

Doing this is sort of messed up, but understandable in some cases. On the one hand, why not just help improve the original project instead of just forking it and writing it your own way? On the other hand, many people do submit PRs to make the original faster, but the owner says something like "I don't like this implementation" or maybe there's extra red-tape in the way. That ends up sparking the "fine, I'll rename my fork and start a new project" which creates a subdivision in the community.

Is having more speed bad?

No, not at all. This is a great thing. But is it the only thing? No. I think what a lot of developers tend to forget about is that there's a lot more that a project can provide than just "speed". For example, what if you had two identical projects, but one benchmarked twice as fast in response time, but the other benchmarked at a quarter the memory consumption? Which project do you choose? Or what about a project that benchmarks at 30% faster, 30% less memory, but the other project has better and easier to understand documentation with a friendlier community?

Lastly, what about that benchmark you're using? What exactly is it benchmarking? Are you benchmarking an app running locally in a Docker container on your 2015 MBP, but your application will run behind a CDN on cloud network? The numbers you get might be a decent gauge to help you filter out what you may or may not want to use. For example, you may benchmark 2 different ways to write a method, and see how much faster one is over the other. Then if you get a 0.5% speed increase, but the implementation is not as readable, is it worth the update?

Benchmark considerations

It's a lot of work to setup a real good benchmark. There's just so many things to consider if you're trying to really compare "apples to apples". Before you blindly look at a benchmark, and make up your mind based on what it says, let's consider a few things first:

• What are you looking for initially? Are you currently using something that could be improved by using something else? Is this research for a new project?
• How does it compare in speed vs the others? This is usually where we start anyway.
• How does it compare in memory consumption vs the others? One project might require 4GB RAM minimum before needing to scale, where another might only need 1GB RAM.
• How well is the codebase written? If you can quickly glance through the source, and understand how things are organized, and what things are doing, this may help you contribute to the project faster.
• Does the community align with your beliefs? Yes, this is not software related, but it's really important benchmark. Do you feel welcomed, or is it hard to get help? This can make or break your project deadlines within your company.
• How is the documentation? Is it all just auto-generated? Is there an easily navigable website? Is it up-to-date? Writing docs is tough, and keeping them up-to-date is tougher, but you don't have time to read the whole codebase just to figure out that the method you need requires 2 arguments.
• What other benefits do these projects offer? They might have specific goals, or features like "human readable error messages", or built-in development tooling.
• How often is the project updated? It's great if some project is actually "blazing fast", but if it's only updated every few months, what happens when your company runs in to a bug, and you reported it 2 months ago with no fix in sight?

Final thoughts

These are all of the main things I look at when considering some project. Don't shoot down a project just because you read 1 benchmark or reddit post that said "Why is X slow?". If you are curious why a specific project is slow, you need to first ask yourself, "what do I consider slow?". Next, give it a shot anyway and run your own personal test. You may just find out that you've had the best pizza of your life that one person on yelp rated 1 star... oh, I mean code... whatever, I'm hungry, it's lunch time.