Antichesse (o ^ω^ o)
Oracle Enterprise est tellement confiante dans son produit phare Oracle Database, qu'elle a introduit des restrictions dans ses conditions d'utilisation interdisant la publication d'études et de benchmarks comparatifs de son outil...
Quand le professeur DeWitt avait réalisé un tel comparatif, Oracle l'avait alors attaqué en justice. Cette affaire est devenue tellement importante que ce type de restrictions s'appelle aujourd'hui une "DeWitt Clause".
A croire que l'entreprise n'a pas confiance en les capacités de son propre produit...
Un article qui compare l'exécution séquentielle vs parallèle des Stream de Java.
En substance :
- Les streams parallèles consomment plus de mémoire.
- Elles deviennent rentables à partir de 1 000 000 d'éléments à traiter
- Sur le PC du mec qui a fait le benchmark, et sans cette info, et avec du recule, son benchmark ne vaut plus grand chose. Par exemple, la parallélisation sur 4 et sur 64 CPU n'aura pas les mêmes effets... Potentiellement, c'est rentable à partir de 125 K éléments, voire moins.
Je viens de tester sur Firefox 119 et Chromium 109.
Résultat : Firefox est un peu plus de 20% plus rapide que Chromium !
- Chrome 106 runs / minutes avec 1,9 d'écart type.
- Firefox 129 runs / minutes avec 3,3 d'écart type.
@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 :
- Beaucoup de RAM
- Pas de problème avec le temps de démarrage
- Un besoin de grosses perfs sur les requêtes de type I/O
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).
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.
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.
Assez simple en fait, il suffit de réunir ces facteurs :
- Câble réseau court.
- Pas de routeur (connexion ad hoc par câble).
- L'option TCP_NODELAY activée.
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.
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.
Une comparaison avancée du mode natif vs jvm de Quarkus. Le benchmark est intéressant.
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.
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 siegeVoici 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.txtPar 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.
Le site donne quelques commandes à lancer sur son VPS afin d'éprouver la bête.
La qualité de cette réponse !!! Date de 2012 quand même
Quelles sont les meilleures cartes SD pour Raspberry (et a fortiori pour clefs USB)
Ici, le tuto compare les performances de StringBuffer et StringBuilder avec JMH