Antichesse (o ^ω^ o)
Je n'ai pas encore migré nos projets mais le gain en temps de compilation semble formidable.
Voici le gain sur un projet cleané :
Et le gain sur un projet déjà compilé avec le build incrémental activé :
Je pense que je vais attendre le prochain patch de correctifs (car il y en aura sûrement) et je migrerai à ce moment-là.
J'étais complètement passée à côté de cela ! L'API time a été repensée en Kotlin pour éviter la confusion de passer une durée en Long et de ne pas savoir s'il s'agit de secondes, de millisecondes, de nanosecondes, etc.
L'idée est d'utiliser les inline-classes (ie. l'enrichissement d'un type existant par un sous-type) et c'est très astucieux regardez :
import kotlinx.coroutines.delay
import kotlin.time.*
@ExperimentalTime
suspend fun greetAfterTimeout(duration: Duration) {
delay(duration.toLongMilliseconds())
println("Hi!")
}
@UseExperimental(ExperimentalTime::class)
suspend fun main() {
greetAfterTimeout(100.milliseconds)
greetAfterTimeout(1.seconds)
}Les Integer contiennent des classes internes qui vont retourner un objet de type Duration et contenant la valeur de l'Integer. De cette manière nous avons la valeur et son type en une seule fois.
Ce langage est tellement réfléchi c'est incroyable.
Pour @Chlouchoutte sur un retour d'expérience d'une équipe Scrum qui a changé son cadre et réduit son temps de travail pour conserver la même vélocité.
Chaque travailleur possède une manière qui lui est propre de gérer son temps. Cette manière de gérer votre temps entre votre travail et en dehors, influe sur votre vie de manière positive ou négative et détermine votre niveau de bien-être. Alors, quel type de travailleur êtes-vous ? Dans son article, Charlotte Cowles, conseiller financier du magazine The Cut, nous présente quelques aspects de comment votre type de travail ou la relation que vous faites entre votre temps et largent...
Je fais partie des piégés visiblement 😩.
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é,
Explication : l'idée est de voir combien de temps prendraient les différents traitements en proportion si 1 cycle CPU prenait 1 sec à la place de 0.3 ns.
Je traduis (en partie) ci-dessous :
| | TYPE D'ACCÈS | TEMPS CPU | ÉQUIVALENT TEMPS HUMAIN
|----------------|--------------------------------|------------------------------------
| | 1 cycle CPU | 0,3 ns | 1 sec
| Dans le | Accès cache L1 | 0,9 ns | 3 sec
| Processeur | Accès cache L2 | 2,8 ns | 9 sec
| | Accès cache L3 | 12,9 ns | 43 sec
|----------------|--------------------------------|------------------------------------
| Mémoire | Accès RAM | 120,0 ns | 6 min
|----------------|--------------------------------|------------------------------------
| Disques | Accès SSD I/O | 50-150 µs | 2-6 jours
| Durs | Hard Disk IO | 1-10 ms | 1-12 mois
|----------------|--------------------------------|------------------------------------
| | Internet SF to NYC | 40 ms | 4 ans
| Réseau | Internet SF to UK | 81 ms | 8 ans
| | Internet SF to Australia | 183 ms | 19 ans
|----------------|--------------------------------|------------------------------------
| | OS virtualization reboot | 4 sec | 423 ans
| Systèmes | SCSI command time-out | 30 sec | 3000 ans
| D'exploitation | Hardware virtualization reboot | 40 sec | 4000 ans
| | Physical system reboot | 5 min | 32 millénaires
Le site du gouvernement nous indique combien de temps conserver quel document, sympa.
Comment booster un peu les temps de build de notre Maven
Pop pop pop
Ohhh le choc ! Cette vidéo m'a glacé les os !
Je ne suis pas toujours d'accord avec Ploum, mais d'une façon générale j'aime bien sa façon d'aborder les sujets qui lui viennent.
Ici la valeur de "notre temps de cerveau disponible".