324 private links
From 2-10 nanoseconds to 700 picoseconds to format a number.
And here is the problem: the encryption performs 2 passes over the data: first to encrypt, then to compute the authentication tag.
As we've seen before, it's bad because you will pay huge penalties when loading / unloading your data to / from memory to / from SIMD registers multiple times, even if you AES-CTR and GHash implementation are optimized to the mooooon.
It reduces the noise of the input and the AI consumes 90% less tokens. These tokens are less noise for the AI to compute.
Source: https://github.com/chopratejas/headroom
The documentation: https://headroom-docs.vercel.app/docs
As always serving raw HTML and CSS for the win. In comparison to NextJS, Astro delivered the same features for 5% of the original bundle size.
A Finite State Transducer seems to be the best algorithm instead of a full index search.
The data don't need to be stored in a database indeed. They only need to be searched as text.
The bun single binary performs better!
64-bits pointer address can be compressed to 32 bits
Passer les PNG/JPEG qualité 90 à AVIF qualité 50 permet d'économiser au moins 75% de bande passante.
L'idée plus innovante est de compresser au préalable les ressources avant qu'elles soient utilisées.
[Précompresser avant de déployer] veut dire qu’on peut les compresser une seule fois, avec le niveau maximum, et demander à nginx de servir directement les fichiers pré-compressés. Zéro CPU à chaque requête, mais surtout un meilleur ratio au final, car on peut compresser plus fort.
En outre, Zopfli permet de compresser en .zip avec 3 à 8% d'efficacité en plus.
# Serve pre-compressed files generated at build time
gzip_static on;
brotli_static on; # nécessite libnginx-mod-http-brotli-static
# Fallback pour les contenus non pré-compressés
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml text/javascript
application/javascript application/json
application/xml image/svg+xml;La compression Brotli permet de compresser à hauteur de 81% le HTML. La score des Web Core Vitals est passé de 70-85 à 99%.
Ok, FreeType renders font on LCD screens 40% faster
Reading a file is actually slow.
getCurrentThreadUserTime() uses many syscalls because it reads from /proc.
clock_gettime(CLOCK_THREAD_CPUTIME_ID) has only one syscall and a direct function call chain.
The optimisation can be done, but:
- The kernel policy is clear: don't break userspace
- It's undocumented anywhere!
- Author's take: if glibc depends on it, it's not going away.
This is why I like browsing commits of large open source projects. A 40-line deletion eliminated a 400x performance gap. The fix required no new kernel features, just knowledge of a stable-but-obscure Linux ABI detail.
The lessons:
- read the kernel source. POSIX tells what's portable; the kernel source code tells what's possible.
- check the old assumptions: revisiting them occasionally pays off.
Optimizations that don't need Rust:
- HTTP range requests for metadata
- Parallel downloads
- Global cache with hardlinks
- Python-free resolution
- PubGrub resolver algorithm
Rust has benefits though:
- zero-copy deserialization
- Thread-level parallelism
- No interpreter startup
- compact version representation: uv packs version into u64 integers. The micro-optimization compounds across millions of comparisons
uv is possible because of many PEP that came since 2016 (so too soon for me): PEP 518, 517, 621, and 658. There are the low-handing fruits: static metadata, no code execution to discover dependencies, and the ability to resolve everything upfront before downloading
How to optimize a rust program to squeeze maximum performance and as little RAM as possible
There are obvious for me, but they are good.
I see some are totally useless for Rust in comparison. Both have different targets though. It is moreover awesome to see 100x improvements.