The Abstraction Penalty

How following best practices of abstraction and encapsulation can hurt performance.
00:00 Intro
00:53 Example walk-through
02:50 Example re-architected
06:33 How does this happen?
08:44 Understanding trade-offs
10:50 Good rule of thumb

[@helshabini]

Great point that I only recently learned after years of building software. Clean code has a heavy price that is often not talked about. Sometimes it is worth it, but often times it is not.

[@bcassol]

Ageeed. And there's also a larger cognitive load if you have to jump through many functions to understand a flow. As a general rule: large callstacks = bad.

[@Drivingralle]

I highly agree

[@valera2010_cool]

It's crazy how uncle bob single-handedly undermined dev industry

[@campbellhutcheson5162]

it looks like a straight up parallelism issue rather than an issue with encapsulation. i don't program PHP but in Python, you could either just call each of the functions concurrently with async (assuming that they are IO bound) or with forked instances of python (for more compute bound tasks for which you need multiple cores). the encapsulation wouldn't matter either way.

[@kronik907]

In the example, he was talking about API calls, which needs batching rather than parallelization. Whereas in other cases parallelization might be a better solution. But I think his point still stands that in either case you have to look at the high level "What are we trying to do here" questions and determine if your overall architecture is going to let you meet your performance goals, and in many cases, the way you choose to encapsulate your code can have a huge impact on how performant your code can be.

[@chauchau0825]

Too much abstraction is bad, too much composition is also bad. Everything is a trade off. There is no correct answer.