Antichesse (o ^ω^ o)
Tout est dans le titre. Comment réduire et optimiser son build Rust.
Je suis bluffée ! Les filters des Stream sont toujours plus lents que les boucles classiques en Java.
Le seul moment où les boucles classiques ne sont pas les plus rapides, c'est dans le cas de figure où la taille des collections dépasse les 500 K éléments et que les Parallel Stream sont utilisées à la place des Stream (et que nous sommes sur une architecture multi-cœurs évidemment) ; sinon les Stream perdent à chaque fois.
On peut résumer l'étude par H.264 (aka. x264) était l'un des leaders incontestés de la compression mais depuis quelques années H.265 (aka x265) offre la même qualité vidéo pour une taille 15-20% inférieure.
Après, H.265 n'est quasiment pas supporté en 2020 tandis que H.264 l'est quasiment partout. Donc pour du web mieux vaux H.264 et pour de stockage/visionnage perso on peut se laisser tenter par du H.265 qui de toute façon deviendra la nouvelle norme d'ici à quelques années.
Incroyable article et super travail ! Encore une fois @Philou tu m'épates à sortir des articles des méandres des internets comme ça.
Ici un comparatif des performances des différents GC d'OpenJDK. Je partais de base sur une hotspot G1, autant admettre que les résultats renforcent mes convictions.
Oh je suis surprise... Spring Boot serait aux micro-services ce qu'une Baleine serait aux petits poissons... LOL
Pour info, nous avons viré intégralement toute la stack Spring Boot depuis trois ans :
- Spring Boot => Sparkjava
- Spring DI => Feather-java
- Hibernate => ActiveJDBC
- Jackson => Jsoniter => Jackson de nouveau (à cause d'ActiveJDBC notamment et de ses récentes améliorations de performances)
- JWT => Petite API perso + Bouncy Castle
- Etc.
Résultats :
- Une application qui passe de 45 Mo de JAR à 6,5 Mo sur le disque.
- Un démarrage instantané.
- Une consommation mémoire divisée par 5 !
Mais bon, Spring est à la mode comme l'ancien JEE et comme son ancêtre il finira par s'effondrer sur lui-même à cause de son propre poids.
Via Riduidel.
Certains se diront à la lecture de cet article qu'ils ont raté leur épreuve de mathématiques parce que c'était au mois de juin et qu'il faisait 27 °c dans les couloirs alors que j'ai fait péter mon score habituel ce jour-là... Ur ur ur :D
Et bien je vous dirai que ce n'est pas du tout ce à quoi je pense. Les hommes et les femmes réagissent différemment aux températures parce que nous ne sommes pas biologiquement identiques ou égaux.
Plus de 3,5 milliards d'années nous séparent de LUCA (Last Universal Common Ancestror) et au moins 200 millions d'années de notre division en deux sexes... C'est une spécialisation incroyable qui transforma les mâles en parasites naturellement séduisants (fourrure pour les lions, ribambelle de couleurs pour les oiseaux, plumages féeriques pour les paons, etc) et les femelles en super-prédatrices (les femelles sont généralement plus grosses, plus fortes et meilleures chasseuses que les mâles dans la nature #BandeDeNazes).
Il serait temps de revenir aux fondamentaux et d'accepter que ne pas être tous égaux dès la naissance ne soit pas une chose grave en soi, mais que ce qui compte c'est d'être traité avec humanité et équité et de traiter chacun de cette façon.
These notes describes how to improve Nginx performance, security and other important things...
Tout est dans le titre.
Lien lien direct.
What it means for software to be fast, and why most software is not.
From a river
Pour Animal et la gestion de nos VPS.
Apparemment, Log4j2 utiliser l'API I/O asynchone de Java8 ce qui le rendrait plus rapide que logback. L'article dresse une comparaison de ces deux frameworks.
Edit : Une fois que la file asynchrone de log4j2 est pleine, ses performances se dégradent bien en dessous de celles de logback.
Du tuning s'impose alors, source Stack Overflow.
Je résume :
- RSA est rapide à la signature et au chiffrement.
- RSA est lent au déchiffrement.
- ECC est moyen pour le chiffrement et déchiffrement.
- ECC est rapide pour la signature.
La NSA a backdoré quelques algorithmed de ECC (ie. les courbes elliptiques) donc bien faire attention avant d'en choisir un !
Le verdict est clair :
- Le plus intéressant d'entre tous est la rémunération via SARL à la condition de cotiser soi-même pour une prévoyance pas trop chère.
- En sachant que le RSI est une caisse non-obligatoire depuis peu, il est possible de cotiser sur des caisses britanniques nettement moins onéreuses.
Je ferai mon changement de status d'ici à la fin d'année.
En résumé, 97,8% des ingénieurs IT provenant d'Inde sont incapables de développer une application :
- Qui compile.
- Qui s'exécute.
- Qui correspond au besoin.
- Qui ne plante pas.
Enjoy l'outsourcing ! Et dire qu'on nous baisse les TJM français parce que "trop cher en comparaison", mais en comparaison à quoi ?
Explication du problème :
La plupart du temps, les VM sont synchronisées avec l'horloge de l'hyperviseur directement et non un serveur de temps. Ce dernier étant lui-même synchronisé avec un serveur NTP (ndr. le serveur de temps).
Le fait est que la synchronisation des threads en Java s'appuie sur des mécanismes de pool de threads et de mise en pause pendant certaines durées ; durées définies par la JVM elle-même et le garbage collector. Or, l'hyperviseur peut - pour des raisons de performances et en cas de partage des ressources physiques entre plusieurs VM - désynchroniser l'horloge des VM avec le "vrai" temps.
Par exemple, il peut y avoir une pause de l'horloge qui dure 40 secondes et l'hyperviseur choisira alors de synchroniser un grand coup les horloges de toutes les VM en cours d'exécution.
Et alors, quel est le problème avec Java ?
Tout simplement qu'à cet instant, tous les threads qui auraient du n'être en pause que quelques millisecondes vont s'activer un grand coup simultanément ce qui va fortement augmenter la charge du CPU et dégrader énormément les performances (puisqu'il n'y a plus partage des ressources via une attribution séquentielle mais concurrence pour accéder à la même ressource : le CPU).
Bref, c'est du caca. En résumé,
Ici, le tuto compare les performances de StringBuffer et StringBuilder avec JMH
Comment optimiser les performances avec SQLite
Un benchmark sur les lambda par rapport aux classes anonymes :
"Enfin, le dernier constat que j'ai pu faire à travers ce benchmark est que, contrairement à ce que j'espérais, l'utilisation d'une lambda à la place d'une classe anonyme n'a pas amélioré la performance d'un tri (temps significativement identiques). L'explication semblant la plus probable selon moi est que les gains de performances annoncés sur les lambdas ne touchent jusqu'à présent que le « linkage » et la « capture » de la lambda (correspondant au « class loading » et à l'instanciation de la classe), mais pas son « Invocation ». Or, l'utilisation d'un Comparator dans une méthode de tri ne nécessite qu'une seule opération de « linkage » et de « capture », puis de nombreuses (n.log(n)) « invocations ». Donc pas d'amélioration majeure côté performance sur ce cas d'utilisation !"
La conclusion du bonhomme est sans appel => ABSOLUMENT AUCUN GAIN sans le parallelize().
Attention aussi : on compare ici les classes anonymes (qui doivent être éviter autant que possible) et les lamdbas. Mais pourquoi ne pas comparer aussi les performances des lambdas avec des classes concrètes, instanciées en singleton hein ?
Actuellement, sans les traitements parallèle, les lambda rendent votre code PLUS LENT et PLUS DIFFICILE À MAINTENIR qu'avec un simple for-each...
Voilà #CestMoche
Un comparatif de performance entre différents serveur web expressifs du type Sparkjava (en java) et Sinatra (en Ruby). Pour rappel, un serveur web expression vous permet d'écrire ce genre de choses :
get("/mon/url", monAction);
post("/mon/url", monAction);
Avec "monAction" qui peut être au choix :
- une lambda
- une instance
- un pointeur sur fonction
En résumé, nous avons les résultats suivants sur un Retina Macbook Pro i7@2.7GHz and 16GB RAM :
-
Golang + bmizerany Pat + GOMAXPROCS(7):
51684 Requests/sec => 1550508 requests in 30s -
Sparkjava:
48631.24 Requests/sec => 1458768 requests in 30s
Average Latency 1.29ms -
Golang + bmizerany Pat:
42222 Requests/sec => 1266661 requests in 30s
Average Latency 1.52ms -
Golang + Gorilla Pat (using Gorillas Muxer)
37756 Requests/sec => 1132689 requests in 30s
Average Latency 1.71ms -
PyPy2.7 Python + Twisted:
12633 Requests/sec => 379001 requests in 30s -
Python + Flask:
11751 Requests/sec => 16393 requests in 30s
Average Latency 55.54ms -
Node + Express:
8962 Requests/sec => 268866 requests in 30s
Average Latency 7.14ms -
Python + Twisted:
3425 Requests/sec => 102781 requests in 30s
Pimper son Linux avec tout un tas d'optimisation sympa. Il faudra que je tienne une liste résumant tout ceci un jour (ou un script).