Typically, the difference between equivalent JSON and Protobuf payloads that have been gzipped is quite small. It can even be that the gzipped Protobuf payload is larger than gzipped JSON one. Granted, there's less data to decompress out of it, which may mean a faster decompression stage, but I'm not sure that's a bottleneck in the first place.
So, do they not compress requests between microservices? Otherwise, how did they see such a reduction?
Dynamic programming problems are banned at a number of companies, and with good reason. Candidates ability to do well on them is largely a function of how much they’ve practiced those problems. I’ve never needed to do dynamic programming with caching of recursive overlapping sub problems ever, and only learned it recently during interview practice.
I generally find Protobuf the serialization format to have no benefits over JSON. Although Protobuf is often thought of as being faster to process and more compact, the reality is that it's usually not (at least as long as you're not working in a systems language like Rust or C++). It's not much faster than JSON to process because in the context of higher-level languages, the time to create usable objects out of the parsed input (which is independent of the serialized data they came from) is usually far larger than the time to parse the payload. And as for being more compact, if you gzip a Protobuf payload and its JSON equivalent, IME they end up being pretty close in size (sometimes the JSON version is actually smaller).
What sort of workloads are those? I have yet to see a workload where macOS's system allocator is not substantially slower than alternatives like jemalloc.
Will this have support for macOS by inserting itself, as jemalloc does, as the default malloc zone? If so, does that mean it will be very fast at determining if a given pointer was allocated by libpas?
On the other hand, I think people listen to his views on politics largely because he's well-known as a chess player. In a sense, people do the opposite of an ad hominem attack, by putting more stock in his arguments because of how respected he is in chess. We have to remember that he's as fallible as anyone else.
I'd be really interested to see benchmarks of Apple's allocator versus others, both in memory consumption and performance. Sometimes, Apple's version of things is worse in almost all use cases, but I'll reserve judgment and wait to see numbers.
mimalloc is briefly mentioned in my article, and I was surprised that it worked on the mac for swapping itself in. I found the performance of it to be roughly the same as jemalloc when I measured
It appears that sorting is done on the memory-mapped buffer? That seems like it could have extra costs (lazily paging in from disk) that we wouldn’t see for an in-memory buffer, and which could affect the benchmark.
On top of these design issues, I'm surprised by how buggy the core experience can be. The home page repeatedly failing to load on many different occasions. The site suddenly acting like you're logged out and needing a refresh. It's very surprising.
Agree that static blogging is nice, but I think this specific look needs some tweaking - for example, there's too low contrast in color between the links and the background at https://inoads.com/blog
The % of programmers that actually need to know any of these numbers is tiny. I've done plenty of optimizations for performance-critical systems and have never known any of these numbers. Certainly, I know general principles like "disk is a lot slower than memory" and "don't block the UI on a network call". But knowing whether an L1 cache read is 0.5ns or 5ns has never been necessary. You can optimize so much "highly optimized" code out there without those numbers. I'm sure there are some people that have to know that stuff, maybe a couple people on an AAA video game title, or computer engineers at Intel. But it's the exception and not the norm.
In that case, if header-only is outside the scope of the license, it begs the question why they would pick that license in the first place. But anyways, it doesn't seem clear from the passage how headers fit in, considering that these headers are not just APIs, they contain the implementation themselves.