Je viens de tester sur Firefox 119 et Chromium 109.
Résultat : Firefox est un peu plus de 20% plus rapide que Chromium !
@Mozilla ajoutez les features qu'on vous demande, la mécanique est bonne. Les Pocket et consorts on s'en fiche !
]]>Résultats surprenant mais expliqués.
En substance, sur les applications codées pour le benchmark, si Java consomme beaucoup plus de mémoire que Rust (entre x3 et x10 en fonction que nous soyons sur Hotpot ou GraalVM), Java est globalement plus rapide que Rust.
Ce résultat qui paraît contre intuitif s'explique par les optimisations que la JRE effectue au runtime, ce qu'un compilateur ne peut pas faire.
Par contre, les temps de démarrage de Rust sont bien rapides que ceux de Java Hotspot mais comparable à GraalVM.
Enfin, si GraalVM consomme 2 à 3 fois moins de mémoire que Java Hotspot (mais toujours plus que Rust), ses performances sont moindre car la compilation native empêche d'effectuer les optimisations au runtime.
En dehors des temps de chargements qui sont forcément plus longs en Java, il faudrait voir ce que la compilation native au runtime pourrait apporter avec GraalVM + Truffle + Substrate VM.
Donc si vous avez :
Alors Java est le choix à privilégier sur Rust et ce résultat est totalement contre-intuitif ! /O\ #Bluffée
]]>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.
]]>Quelques benchmarks sur des serveurs http. Je partage surtout pour les lignes de commande de siege
(l'utilitaire de benchmark utilisé).
En ce moment je regarde rapidoid et undertow, je recherche des serveurs web ultra-rapides et ultra-légers pour faire de l'embarqué sur du GraalVM natif (et peut-être remplacer Sparkjava qui ne reçoit plus de mises à jour).
— Liens directs
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.
— Liens directs
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.
— Liens directs
Je regarde les différentes implémentations des files FIFO thread-safe sur JVM.
Je mets également ce lien car il complète très bien les informations du premier.
— Liens directs
Assez simple en fait, il suffit de réunir ces facteurs :
Et dans l'ensemble, puisqu'en loopback le même CPU calculera les checksums et les handshakes que font deux machines en temps normal, alors la boucle locale sera plus lente.
— Liens directs
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 :
Résultats :
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.
— Liens directs
Une comparaison avancée du mode natif vs jvm de Quarkus. Le benchmark est intéressant.
— Liens directs
Déterminer la charge soutenable par votre service REST en déclarant les requêtes via une syntaxe Yaml proche de celle d'Ansible.
Via Doo.
— Liens directs
Ohhhh ce benchmark sur Kotlin ! Sur certains points Kotlin est plus rapide que Java mais pas tout le temps et il y a des choses à éviter absolument comme les varargs
.
Pour résumer l'article :
Plus rapide que Java | Mois rapide que Java |
---|---|
✅ Higher-order functions | ⛔️ Varargs + Spread Operator |
✅ Lambda expressions | ⛔️ Delegate Properties |
✅ Companion Objects | ⛔️ Ranges (forEach function) |
✅ Local Functions | |
✅ Null safety | |
✅ Indirect access to Range | |
✅ Ranges (local, non-primitive types) | |
✅ Ranges (iteration with explicit step) | |
✅ Use of indices on custom collection |
Je réponds à ton post Lenny. En cherchant un peu je suis tombée sur un soft de benchmark en ligne de commande qui s'utilise hyper simplement : Siege.
Comment est-ce qu'il s'installe :
sudo apt install siege
Voici quelques exemples pour t'aider avec AC.
# Lancer un benchmark pendant 60 sec
siege -b -t60S http://www.cakeozolives.com/shaarli-antichesse/
# Lancer 50 clients requêtant entre 0 et 10 sec pendant 1 minute
siege -c50 -d10 -t1M http://www.cakeozolives.com/shaarli-antichesse/
# Faire pareil mais en requêtant plusieurs URL
siege -c50 -d10 -i -f site.txt
Par exemple avec mon Shaarli :
$ siege -b -t60S http://www.cakeozolives.com/shaarli-antichesse/
** SIEGE 4.0.4
** Preparing 25 concurrent users for battle.
The server is now under siege...
Lifting the server siege...
Transactions: 1881 hits
Availability: 100.00 %
Elapsed time: 59.22 secs
Data transferred: 20.38 MB
Response time: 0.75 secs
Transaction rate: 31.76 trans/sec
Throughput: 0.34 MB/sec
Concurrency: 23.77
Successful transactions: 1881
Failed transactions: 0
Longest transaction: 9.89
Shortest transaction: 0.06
]]>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.
— Liens directs
Le site donne quelques commandes à lancer sur son VPS afin d'éprouver la bête.
— Liens directs
La qualité de cette réponse !!! Date de 2012 quand même
— Liens directs
Quelles sont les meilleures cartes SD pour Raspberry (et a fortiori pour clefs USB)
— Liens directs
Ici, le tuto compare les performances de StringBuffer et StringBuilder avec JMH
— Liens directs
Un benchmark en Yarn et NPM qui montre que Yarn "ça trou le cul !". Yarn est vraiment plus rapide que NPM d'un facteur 2,5 à 25 !
— Liens directs
Je mets ici les liens vers les benchmarks des différents frameworks en JS :
]]>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
— Liens directs
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 :
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
Benchmark de lib JS
— Liens directs
Les FlexBox ont de meilleurs performances que les autres mode d'affichage. Elles sont plus simple à mettre en oeuvre et interopérable/compatible avec tous les navigateurs de nos jours.
Elles s'apprennent en 4-5 jours pour un début ou une débutante en web, c'est-à-dire n'ayant jamais touché à HTML et CSS (Roudoudoutte, spourtoi).
FlexBox : faites le pas !
]]>Écrire des benchmark facilement en Java.
— Liens directs
Les publicités sur internet vous pourrissent la vie de plusieurs manières :
1) Elles vous importunent avec du contenu marketing.
2) Elles violent votre vie privée en déposant des cookie traceurs dans votre navigateur.
3) Elles rendent difficile la lecture des pages en ajoutant du contenu mouvant / coloré / etc.
4) Elles ralentissent votre surf de manière drastique.
Ici, un article qui mesure la vitesse de chargement d'une page web avec et sans pub. Imparable.
— Liens directs
Un petit post sur OpenJDK (un peu vieux le post certes) mais très sympa.
— Liens directs