I hear LISP has a pretty good macro system...
584 karma · joined October 10, 2013
https://calendly.com/jpochtar
See https://medium.com/@jaredpochtar/on-performance-and-software... and the full section on https://medium.com/@gabriel_20625/technical-lessons-from-bui...
> Most of the code we wrote was fast enough (<2ms) that making it faster wouldn’t be noticeable, so it would definitely be a waste of time to optimize. Making code that’s 0.1% of your runtime 100x faster only makes your latency <1% lower.
I don't want you to think we didn't care about performance. We did— a lot. We just think most people do performance optimization badly.
There's a lot of superstition on the internet about how to structure your code so it's fast. In our experience, following this advice usually does not make your code fast. Most people have bad intuition about performance.
To counter this, you have to constantly measure the performance of your code.
There's 2 parts to this idea.
1. Most things are fast enough that optimizing them is not worth making the code less readable, and is a waste of time.
2. Measuring, rewriting, and repeating is the right way to do performance anyway, full stop. There's lots of superstition around performance, which is absurd because it's extraordinarily measurable.
For point 1:
We goalled on a clear and flexible style, which helped us move incredibly fast with very few people. See https://norvig.com/spell-correct.html for an example of a golden piece of code in this style. Rewriting for performance takes moves us away from that goal.
Most of the code we wrote was fast enough (<2ms) that making it faster wouldn't be noticeable, so it would definitely be a waste of time to optimize. Making code that's 0.1% of your runtime 100x faster only makes your latency <1% lower.
It's not because we're brilliant coders: we just realized that most of the code we wrote ran on arrays with few enough elements that even O(n^2) algos could run in <1ms. Some of the code we wrote ran on a server, where network was the dominant factor, and we could always just scale up our servers with money. Some of the code ran on click, where it could be as slow as 5 seconds without the user really caring.
For point 2:
There's no such thing as “fast” code and “slow” code— you can put in the work to optimize any piece of code, and make it incrementally faster.
Because you can put in work to optimize any particular code, we either budgeted hours of engineering time for performance, or set performance goals. In either case, you want to spend your time optimizing the code that's the slowest, so you get the most “bang for your buck.”
Most people have terrible intuitions about performance. We certainly did— if we'd prematurely optimized the things we'd thought were going to be slow, we'd have wasted a ton of time
I felt there were lots of superstitions about performance that were just wrong. For example, considering big-O time complexity was often wrong for us, because our n was usually pretty low, so we were dominated by constant factors.
Performance is incredibly measurable. You should always measure, rewrite, and repeat until you hit your perf budget. Otherwise you're just shooting in the dark.
Because we goalled on clean code, tearing and replacing whole subsystems for performance was relatively easy.
> we were too focused on the technical side
Yes. Oh boy we were.
> should probably pick the most boring stack
Agreed. I'd worked in the Coffeescript compiler so it was "boring" for me, but you should pick whatever's "boring" for you— likely not Coffeescript
Ultimately we didn't get all the way there, which is part of why we closed up shop
((o) => o[expr_to_switch_over()])({
opt1: () => {
stmts();
},
opt2: () => {
stmts();
},
opt3: () => {
stmts();
}
})Jump ahead 30 years and just use LISP already.
Of course not: CSS is a bad idea in 2019. In 2004 it solved some of the problems we have React to solve today, but much, much weaker
YIMBY is too incremental— turn SoMa into mini-Manhattan to jump SF 100 years into the future!
We could solve it if we checked performance like we do unit tests, and held developers accountable to a literal performance budget set by the business.
> Few teams I’ve encountered have actionable metrics associated with the real experiences of their users.
Imagine getting latency numbers on load times, bundle sizes, TTI, and so forth on every commit. PRs that blow the performance budget would be immediately flagged. You could plan for performance like any other business cost.
Even nontechnical business leaders can understand reports like "3s load time", and set tech team goals based on a relationship between load times and lost sales. "Load time must be under 2s, even on old Android + Edge" is something everyone can understand.
The article is right: what's most pleasant for the developer isn't necessarily what's best for the business. If metrics like load times are only being seen by developers, the developers have a moral hazard: either they
1. make choices that benefit themselves, at a cost to the business
2. make their own lives voluntarily worse, without recognition
The article is right again that sometimes, better DX is in fact worth worse performance for the user. As with anything, it depends on the business.
But businesses won't accurately and fairly decide on their preferred tradeoff if only engineers are in charge of it.
We need better performance infrastructure!