Mateus Guimarães

Speed and benchmarks do not matter; at least, not the way we think

Published over 1 year ago • 3 min read


On the last few weeks I have seen lots of discussions about speed in the Laravel community (and some other communities, for that matter) and I thought I share a few thoughts here.

First, as developers I would say we are always going to think about performance — we want to write good code that is performant. Period. With that said, I also think it is easy to misunderstand where we need to make optimizations and where the problems lie.

To be clear, I am thinking of a specific thread that mentioned Laravel was “slow”. Now, I am 100% a Laravel fanboy, so you might be thinking that I’m going to defend it… The first thing is that we have to define what is slow. It can’t be “slow” per se — is >20ms slow? Maybe 50ms? Maybe 100ms? We usually classify a language or framework as slow by comparing it to others.

I’ll give that Laravel is not so fast in the comparisons we often see, because it is usually compared to complete different beasts. Laravel is a full-stack framework with TONS of features, so it’s natural for it to be slower than something like Express (which is basically a router) or a barebones framework that doesn’t ship with almost anything. Now, that does not make Laravel slow. Laravel can be quite fast, actually — probably much more faster than most of us will ever need.

This email is not about Laravel though — it’s about early optimizations, micro-optimizations and speed. I already went a bit in depth about scaling Laravel on this article, but I want to share some extra thoughts here.

Every web application is a distributed system of sorts these days. You have the user on one end, a server running NGINX and PHP, maybe a different server running your database and cache service, your application might call several external APIs, etc — that is, you have lots of possible bottlenecks — your PHP application is just one of them.

We have lots of computing power these days, so even if you write poor, performant code, you’ll probably still be fine. I’m not saying that you should write bad code, all I’m saying is that our current tools do a lot for us. And, from my experience, the bottlenecks usually come up at different places than the application — a database without proper indexes and bad queries is a perfect example of this — you think your app is slow, you add an index and boom - it just works.

Now, to my main point about speed — speed definitely matters — we don’t want to run slow code, but as I said, most modern languages are fast enough and there are other factors we should be looking into: the community, the developer experience, the ecosystem, the familiarity of a team with a language, etc. — speed is just one of those factors. Were it the prime and definitive factor, we’d all be writing C and Go only — that’s totally not the case.

There’ll certainly be situations where you specifically need a lot of performance, and in those scenarios, you’d definitely want to pick the appropriate tool for the job, but I’d argue that’s not the norm in web development. Most languages and frameworks are more than fast enough, computing power is readily available these days, scaling is much easier than it was before and we have lots of distributed pieces that could cause slowness other than the app itself. There are also lots of things you can do to speed things up: add a caching layer, offload processing to background workers, etc. — so it’s not black and white.

Okay — I feel this email was a bit confusing. To try and summarize my thoughts: in my opinion, speed is important, but not the only important thing — most apps will be fast enough, you have other things to look at (database, API calls, random I/O) that could impact speed, you have several ways to make your app faster (queues, caching, etc) and as long as you don’t write very poor-performant code, you will likely be just fine.
I’ll also add that PHP is a very fast language these days — and we have lots of tools in the community to make it even faster (Swoole, RoadRunner, Octane, hyperf, etc). You can do wonders with it.

Alright, I’m out — if you’ve had any experiences where you needed to attain high performance or if you faced low performance even while doing things right, I’d be very interested to know. Shoot me an email!


Mateus Guimarães

Read more from Mateus Guimarães

I was reading some tweets about scaling and how Laravel was a bit behind other frameworks and I remembered I have a cool scaling story to tell. Jack Ellis already wrote a very interesting blog on how Fathom Analytics scaled Laravel, but my story is about different. You're about to read how we scaled to over a hundred million jobs and peaks of 30,000 requests/minute a timespan of only twelve hours, using nothing but Laravel, MySQL and Redis. First, I must give some context: in 2019 I joined a...

almost 2 years ago • 7 min read

One very common question among people who started testing their stuff is..."Okay, now what? How do *actually* use this?" It is fairly easy to teach the basic concepts of testing, but it's really hard to teach people how to leverage testing/TDD to solve complex problems, especially with simple examples. With that said, there's no better way to teach that than test-driving a feature on a real application. Not a dummy ecommerce or blog, but an actual application that has complex features and...

over 2 years ago • 1 min read

Hey there, I'm writing to let you know of my newest project: 30 Days of Laravel. The idea here is to produce 30 short, easily digestible videos that you can watch real quick during your lunch break. They'll teach small tips and tricks on PHP and Laravel, and you might already know some of them, but I'm sure you'll learn new stuff 🙂. The goal is to send an e-mail, every day, for 30 days. It'll include the video, an in-depth explanation and documentation references. I have yet to finish...

over 3 years ago • 1 min read
Share this post