Réutiliser le code traduit peut supprimer une partie du lancement suivant. Cela n’élimine pas tout le travail de démarrage et ne garantit pas le même gain partout.
Une exception importante au nouveau défaut
L’annonce 0.4.4 active DynaCache compressé avec une limite de 2 Go, sauf pour les programmes utilisant BOX64_DYNAREC_DIRTY. Elle ajoute le configurateur Python des profils applicatifs. La commande documentée box64 -dl détaille le cache ; box64 -dc retire les entrées obsolètes. La seconde modifie le cache, la première sert à l’inspecter.
La traduction n’est qu’une partie du démarrage
Notre exemple fictif décompose un démarrage à froid en 3 secondes de traduction et 7 secondes d’autre travail : 10 secondes au total. Si un cache compatible remplace la traduction par 1 seconde de chargement, le lancement suivant prend 8 secondes, soit 20 % de moins. Ce calcul ne représente pas une mesure de Box64.
Le reste peut comprendre bibliothèques, lectures de fichiers, initialisation et préparation graphique. DynaCache n’est pas un cache de shaders GPU, même si les deux peuvent accélérer les lancements répétés. Les confondre complique le diagnostic d’un démarrage lent.
Conserver un profil qui fonctionne
Avant de retirer un réglage, notez le profil actuel et le problème qu’il corrigeait. Testez une modification à la fois, avec la même version du programme et les mêmes entrées. Un nouveau défaut peut rendre un contournement inutile ; une optimisation générale ne prouve pas que chaque réglage local est obsolète.
Comparez lancements à froid et répétés, puis vérifiez les résultats ou l’arrivée au même état jouable. Relevez le backend et le matériel hôte. Une démonstration sur une machine ARM64 ne classe pas ARM64, RISC-V et LoongArch comme architectures si processeurs et GPU diffèrent. Le résultat utile est une amélioration reproductible sur votre propre équipement.
Revue du 8 septembre : exclusion DIRTY ajoutée, cache de traduction distingué des shaders ; conseils de réglage systématiques remplacés par une comparaison contrôlée.