4 ms·
tl;dr: Hardware is cheap. Engineers are expensive. > Instead of fearing the overhead in PHP for function calls, Already in 2015 in almost all applications thi
by chx 2y ago
tl;dr: Hardware is cheap. Engineers are expensive.
> Instead of fearing the overhead in PHP for function calls,
Already in 2015 in almost all applications this is a premature optimization which is rightly known as the root of all evil. Please. Your app will talk to the network, likely run a database query which is like thousands or millions of times slower than a function call. Further, even if there is a measurable difference the cost of hardware which makes that difference go away is very likely to be smaller and much smaller at that than the cost of the engineering hours wasted during maintenance when wrestling with code which was written with a "function calls are expensive" mindset.
This doesn't mean you don't need to worry about performance and scalability but even that is going to be much easier if you have a well structured code.
- ec109685 2y agoIO has a very different cost than wasting CPU cycles, so shouldn’t necessarily be lumped together when analyzing tradeoffs. Your point still stands that fundamentally changing the design of code should limited to the hottest parts. Probably the biggest risk to this style map/reduce code is that you end up having IO deeply nested running synchronously versus grouping operations that can be run in parallel.
- juangacovas 2y agoWell, in my particular experience with juniors, it's astonishing the so many ways they have to make any code run slower than it has to be (besides the network and database queries), just by thinking 'nah, this is a computer and it can do millions of ops by second'. And that's why I always take the "premature optimization" dogma with a grain of salt while my life's miserable enough having to accelerate some other's stuff.