Une base de donnée type Graph basée sur du JSON.

Ils affichent des performances équivalentes voir meilleurs que MongoDB et Postgres sur des opérations tels que:

• single write
• single read

Sinon côté features d'une DB graph, à priori ils font beaucoup mieux que Neo4J, le principal concurrent.

Leur langage de recherche ressemble à du pseudo-code:

FOR doc IN users
  FILTER doc._key == "phil"
  RETURN doc

Un article sur l'insertion spéculative dans Postgres et les améliorations de performances qu'elle apporte.

L'insertion spéculative est faite avec la construction INSERT… ON CONFLICT.

Cette variante vérifie d'abord que l'insert peut être réalisé, ce qui évite la création de "dead tuples" qui sont des lignes n'ayant pu être insérées mais quand présentes jusqu'au prochain garbage collect (vacuum).

Sur une table ayant 1 millions de dead tuples, il y a une différence de perfs de presque 8000% au SELECT ! (0.7 ms vs 54 ms)

Les insert ayant échoués vont aussi incrémenter les ID de transaction et après 200 millions, cela va déclencher le garbage collector pour un nettoyage mais aussi ralentir toute la base de données.

Finalement, tous ces dead tuples consomment aussi de l'espace de stockage.

Bref, il est temps de passer à INSERT… ON CONFLICT DO NOTHING 😄

(Merci Gaël pour le partage)

Des conseils pour offrir la meilleure expérience possible lorsqu'on utilise des polices de caractères personnalisées.

• Utilisez des petites polices (20-40Kb)
• Servez les vous même (pitié pas Google Font..)
• Ne proposez pas de polices intermédiaires (font-display: block;)
• Indiquez au browser de pré-charger les polices (<link rel="preload" ...>)

Le but est de charger les polices au plus vite car aucun texte ne s'affiche avant et c'est volontaire pour éviter le layour shift (des éléments qui changent de place quand la police est chargée si elle ne fait pas exactement la même taille que la temporaire)

Une lib pour manipuler des données tabulaires (vectors, matrices) de la même manière qu'avec Panda.

Celle la est écrite en Rust donc on peut s'attendre des à des performances ~7x plus rapide que Panda. (Benchmarks)

(Via Alex)

Un projet qui permet de lancer des scripts Python avec des performances natives en compilant le code en bytecode LLVM puis donc en code natif.

Ils affichent des performances x10 à x100.

Par contre toutes les libs ne sont pas forcément supportées donc difficile de faire tourner une grosse codebase avec ça.

J'avais déja parlé de Taichi qui propose le même genre de chose.

Un article d'investigation puis de correction de problèmes de performances sur un grosse application React utilisant les Hooks.

Un document interne technique la manière d'optimiser la destructuration d'array qui est massivement utilisé dans les React Hook.

C'est intéressant de voir que la destructuration d'objets était plus légère et rapide que la destructuration d'array (64 bytes d'instructions vs 305).

La destructuration d'objet est même plus rapide que de faire:

const array = useState(),
 count = array[0],
 setCount = array[1];

Ces différences sont très légères et uniquement observées sur le bytecode non optimisé.

Une alternative au compilateur officiel TSC pour Typescript.

C'est beaucoup plus rapide (~100x plus rapide) car:

• écrit en C++
• écrit uniquement pour les versions récentes de TS
• cache des fichiers compilés

Il utilise un bytecode intermédiaire pour représenter le typescript et conserve un cache pour ne prendre en compte que les dernières modifications.

Par contre toutes les fonctionnalités ne sont pas supportées.

(Merci Sébastien pour le partage)

Il ne faut pas forcément se focaliser sur la performance à tout prix ou sur la maintenabilité à tout prix.

C'est toujours une histoire de compromis entre les deux.

J'aime beaucoup cette citation qui me fait pensé au mécanisme de gestion mémoire de Rust:

Sharing state is fine, so long as we don’t mutate it.
Mutating state is fine, so long as we don’t share it.

Un outil de load testing open source en alternative à Gatling.

Ils supportent le scripting en Javascript et de nombreux protocols: HTTP, WebSocket, GraphQL et même gRPC!

Il est aussi possible d'enregistrer un scénario dans son navigateur et de le rejouer.

Whoa Taichi est un langage compilé avec une syntax proche de Python qui permet de booster les performances d'un code python quasiment sans le modifier !

Simplement en important la librairie et en rajoutant des annotations, on peut avoir jusqu'à x100 en performances:

import taichi as ti
ti.init()

@ti.func
// python func here

Taichi exploite automatiquement le parallélisme des CPU de la machine et même du GPU.

Un exemple d'utilisation des Protocol Buffers en Node.js.

L'exemple utilise l'excellente lib Protobuf.js qu'on utilise aussi dans le coeur de Kuzzle pour la communication entre les noeuds du cluster ;-)

J'en parlait ici aussi https://links.aschen.tech/shaare/R6dzhw

Un REX du gouvernement Britannique qui a enlevé JQuery de ses pages (32Kb compressé).

Ils ont observé une amélioration de 17% des performances en moyenne!

Par contre, ils n'ont pas utilisé d'autre lib JS à la place non plus :-)

Très bonne explication du fonctionnement et des usages de Protocol Buffer, le standard pour encoder et partager des données binaires.

C'est un pseudo langage pour représenter de la données, des nombres, des strings, etc

message Event {
  fixed32 count = 42;
  string user = 'aschen' ;
} 

Des librairies sont disponibles dans tous les langages pour encoder / décoder des messages protobuf.

On peut s'en servir pour envoyer des messages sur le réseau de manière performante (par rapport au traditionnel JSON) mais aussi pour stocker des objets dans des fichiers.

Dans Kuzzle on s'en sert pour une communication efficace entre les nœuds du cluster par exemple

On commence à voir des tests des performances de Bun par rapport à Node.js.

Pour l'instant il manque encore trop de compatibilité à Bun avec les lib Node.js pour pouvoir aller très loin (pas de child_process) par exemple.

Dans cet article, l'auteur note un gain sensible de performances avec Bun.

Une utilisation intelligente des instructions SIMD pour faire de la recherche de sous chaines de caractères

Les instructions SIMD ont été créées pour manipuler directement des nombres de 128, 256 et 512 bits (pour faire du SHA en gros)

Pino est un logger très performant pour l'écosystème Node.js.

Il est 2 à 3 fois plus rapide que Winston et ce n'est pas rien car les logger sont des composants critiques des applications !

Pino s'occupe exclusivement de rediriger les logs sur la sortie standard et ensuite celle-ci peut être rediriger vers des transports Pino pour les services d'agrégation les plus communs