We can expect a x8 speedup for a big transaction.

Optimization is not always a progress in every field

Similar to https://shaarli.lyokolux.space/shaare/xwiTHQ

Bit operators are the fastest, then static array, then dynamic arrays.

Objects are heavy in comparison.

PRAGMA journal_mode = WAL;
PRAGMA synchronous = NORMAL;
PRAGMA busy_timeout = 5000;
PRAGMA cache_size = -20000;
PRAGMA foreign_keys = ON;
PRAGMA auto_vacuum = INCREMENTAL;
PRAGMA temp_store = MEMORY;
PRAGMA mmap_size = 2147483648;
PRAGMA page_size = 8192;

Hashsets < Dynamic Array < Statis Array < Bit Mask

How to cache? It depends of the context: push vs pull and owned vs user.

Push means that the asset is pushed to a central server and then distributed.
Pull means the asset is referenced and the central server has to “pull” the content.
Owned means it’s owned by the central server.
User means it’s user-submitted content.

Push + owned

Make everything push + owned content if possible. "It turns out, however, that you can make a shit ton of other stuff push + owned if you try a little harder. "

How does the client check if they're expired?
Use “stale while re-validate”. Ur welc’

In summary:

• store asset
• use stale-while-re-validate access patterns
• should work offline

Push + User & Pull + Owned

Handle these with hash URLs. Hash the URL and treat it immutably.
Push + User: Forum comment -> hash URL
Pull + Owned: "in-content" assets. That’s where it’s user generated content, but not owned by the server.

Summary:

• Load asset
• Use infinite TTL + hashed URLs
• Should not re-fetch across page/app reloads

Pull + User

That’s where it’s user generated content, but not owned by the server. Posting gifs into the chat is a prime example; linking a blog post and generating a media upload for that is another.

Guess what: this pattern fits for highly dynamic user-generated content, which means it’s the content users link to each other in-platform.

Stable URL, short TTL. YES, SHORT TTL. [...] Debounce + throttle? Sure. Micro-TTL? Yes. Cache? Never.

See also https://jpegxl.info/art/

Also called german strings. This is a great data structure that explains how handling strings can be diverse.

Read ahead of time of the safety bound of the kernel...

An optimisation that I don't really understand.

10 to 20% performance boost... that's great!

About running Blue Dwarf

A lightweight 70 KB implementation of the Jinja template engine. It was 130MB with the python environment and moustache divided the payload size by 1857! It is useful to run it for CI/CD pipelines if a subset of Jinja is needed.

How to configure SQLite for

Using a simple INT with Unix millisecond timestamps is the best for performance.
COUNT is slow, so it can be useful to keep track of them in a separate table.

Distributed SQLite databases can be achieved the same way as PostgresSQL: one writer and multiple replicated readers.

Great insights too :)

I created a Cargo subcommand called cargo-wizard that simplifies the configuration of Cargo projects for maximum runtime performance, fastest compilation time or minimal binary size.

Avoid a round trip for the slow start TCP algorithm. Depending of the internet connexion it can save 100s of ms.

Some tricks the author uses and explains:

1. using <link rel="preload" as="ROLE" href="URL">` to download
2. lazy-loading the search index (and this feature) as it is not used widely, and costs bandwidth (1.8MB)
3. Reducing the cost of webfonts: shrinking the typeset of the font (especially for titles) + combining css files

The author reduced the page load from 11 seconds to 4 seconds with these.

There’s a standard way to make part of a page not visible until the user requests it: the

tag. You may have seen this on big code examples in some of my other posts.