L’article de Chris Down, expert en gestion mémoire Linux, clarifie les différences entre zswap et zram, deux technologies de swap compressé souvent mal comprises. L’idée principale est de privilégier zswap dans la plupart des cas, car il compresse les pages en RAM tout en transférant automatiquement les données froides vers le disque, optimisant ainsi l’utilisation de la mémoire. À l’inverse, zram crée un périphérique bloc compressé en RAM avec une capacité fixe, ce qui peut entraîner des problèmes si la mémoire est saturée, comme des plantages (OOM) ou une dégradation des performances.
L’auteur souligne que zram n’est adapté que pour des cas très spécifiques, comme les systèmes embarqués ou ceux nécessitant une sécurité renforcée (éviter l’écriture sur disque). Il met en garde contre l’utilisation conjointe de zram et de swap disque, qui peut aggraver la pression mémoire en déplaçant des données actives vers le disque lent. Pour les serveurs, zram pose aussi des problèmes de comptabilité des ressources, car son usage n’est pas intégré aux cgroups.
Enfin, l’article explique que les recommandations simplistes ("utilisez zram pour préserver votre SSD") sont souvent infondées. Le choix dépend du contexte : zswap est plus flexible et moins risqué, tandis que zram, bien que performant dans certains scénarios, exige une configuration rigoureuse (comme un gestionnaire OOM utilisateur) pour éviter les blocages.
L’article explique que le système de réactivité de Vue 3, basé sur des Proxy ES6, devient un goulot d’étranglement avec de gros volumes de données car il transforme récursivement chaque objet et propriété en élément réactif, ce qui peut créer des centaines de milliers de proxies, bloquer le thread principal et faire exploser l’usage mémoire (par exemple un JSON de quelques Mo pouvant être multiplié en mémoire). Il en résulte des gels du navigateur et des performances dégradées, notamment lors du rendu de grandes listes, et l’article propose d’éviter la réactivité profonde par défaut en adoptant des stratégies comme la réactivité partielle, le stockage non réactif de données volumineuses ou des patterns de chargement et transformation plus ciblés afin de limiter le coût CPU et mémoire.
Tout est dans le titre
Tout est dans le titre
Comparaison entre la consommation mémoire d'un module Node et du même module en Rust... Ça vaut le coup de se pencher sur Rust
L'auteur vulgarise l'architecture de Von Neumann : comment fonctionne la RAM, sa relation avec le CPU, etc. L'article est long mais se lit très bien
L'un des problèmes de la récursivité est le dépassement de mémoire, chaque appel récursif ajoutant des données à mémoriser. Il est possible d'éviter cela tout en conservant la récursivité en utilisant la récursion terminale. Au lieu d'écrire
function factorielle(int n) {
if (n <= 1) {
return 1;
}
return n * factorielle(n - 1);
}
Tout est dans le titre
Un logiciel de flashcard pour l'apprentissage
Tout est dans le titre
Il s'agit d'une BD sur la technique de la répétition espacée
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre... Article très long mais très exhaustif sur le sujet
Tout est dans le titre
Tout est dans le titre
Technique intéressante pour mieux mémoriser