Le temps de chauffe correspond à la période pendant laquelle le code est interprété
Même pas vu que tout ce qui va être exécuté après l'écran de démarrage va être lazy loadé ;)
Je peux arriver à l'écran super rapidement et tout chargé après. Typiquement tu peux arriver à ton main en <50ms si il ne charge rien.
le code est interprété puis passe dans le JIT parc qu'identifié comme étant appelé régulièrement par la JVM
Ca dépend des options entre -client, -server et UseTieredCompilation pour HotSpot
la "chauffe" continue donc après le démarrage "visible" par l'utilisateur
Oh que oui. La chauffe peut même ralentir le code. Disons que ton code charge après 10 minutes une nouvelle classe. Hotspot va detecter que l'optimisation qu'il avait fait n'est plus valide (typiquement on peut transformer un appel virtuel en appel static si une seule implémentation) et bingo. Bon ca c'est pour l'annecdote ;)
En pratique on arrive au régime stable "assez rapidement" typiquement les micro-benchmark se stabilisent dans les 5/10 secondes. Passé 3 secondes, les gains restant sont généralement de l'ordre de 10-30%. Les macro bench prennent un poil plus selon la complexité du bordel et le tas de truc à charger (oui avoir 300 libs pesant 60Mo ca aide pas).
Le temps de démarrage correspond plutôt au chargement par l'OS de la JVM
C'est ca qui coûte le plus cher à froid car le runtime est assez gros: ~1s avec les caches de la VMM vides, ~50ms avec les caches pleins.
Après on commence à charger les boûts de runtime non utilisés pas le bootstrap.
Dans l'ensemble la discussion est malheureusement assez inepte tellement elle est peu cadrée et sans référence. Pire encore des gens font comme moi et utilise des références desktop dans une discussion qui s'applique à un autre contexte.
[^] # Re: ça marchera jamais?
Posté par ckyl . En réponse au journal Ubuntu Edge : Révolution ou bide annoncé ?. Évalué à 6.
Même pas vu que tout ce qui va être exécuté après l'écran de démarrage va être lazy loadé ;)
Je peux arriver à l'écran super rapidement et tout chargé après. Typiquement tu peux arriver à ton main en <50ms si il ne charge rien.
Ca dépend des options entre
-client,-serveretUseTieredCompilationpour HotSpotOh que oui. La chauffe peut même ralentir le code. Disons que ton code charge après 10 minutes une nouvelle classe. Hotspot va detecter que l'optimisation qu'il avait fait n'est plus valide (typiquement on peut transformer un appel virtuel en appel static si une seule implémentation) et bingo. Bon ca c'est pour l'annecdote ;)
En pratique on arrive au régime stable "assez rapidement" typiquement les micro-benchmark se stabilisent dans les 5/10 secondes. Passé 3 secondes, les gains restant sont généralement de l'ordre de 10-30%. Les macro bench prennent un poil plus selon la complexité du bordel et le tas de truc à charger (oui avoir 300 libs pesant 60Mo ca aide pas).
C'est ca qui coûte le plus cher à froid car le runtime est assez gros: ~1s avec les caches de la VMM vides, ~50ms avec les caches pleins.
Après on commence à charger les boûts de runtime non utilisés pas le bootstrap.
Dans l'ensemble la discussion est malheureusement assez inepte tellement elle est peu cadrée et sans référence. Pire encore des gens font comme moi et utilise des références desktop dans une discussion qui s'applique à un autre contexte.