why does everyone pick sides with programming languages, and then refuse to use anything else
who cares, they're basically all the same, just marginally different syntax
More languages, more insights!
A few interesting takeaways:
* Java and Kotlin are quick! Possible explanation: Google is heavily invested in performance here.
* Js is really fast as far as interpreted / jit languages go.
* Python is quite slow without things like PyPy.
Did you know that a random SSD read is multiple orders of magnitude slower than a random memory read?
I made a little visual that really drives the point home.
This is why memory buffers and caches are so important, especially for I/O heavy workloads like databases.
1 billion loop iterations. 4 languages.
I wrote the same code in js, python, go, and c. Timed executions on a digital ocean dedicated cpu vm, and here are the visualized results.
Not all programming languages are created equal!
00:00
Readers added context they thought people might want to knowReaders added context
The JS/Node benchmark has an unoptimized loop. When fixed, it is second fastest behind only C/gcc.
x.com/benjdicken/sta…
Context is written by people who use X, and appears when rated helpful by others. Find out more.
Over the past 8 days, I received over 100 PRs on the languages repo with additions and improvements.
- A bunch of languages were added
- Some implementations got tweaks to modify performance
- The run script now uses hyperfine for timing
Thanks to all the contributors.
I spent 250+ hours over 6 months working on the IO devices article. Here's a little BTS 🧵detailing what goes into making an article like this, and how to use it to both educate + effectively market a product.
Want to understand B-trees better?
Try btree.app and bplustree.app.
These are standalone sandboxes of the visuals I built for my "B-trees and database indexes" article. Helpful for learning B-tree insertion, search, and node splits.
Never call an API in a transaction.
In relational databases, it's best practice to keep transactions as short-lived as possible.
Longer transactions lead to more resource contention. If each transaction acquires row locks, being longer-lived means higher likelihood of lock
