C'est une utilisation déplacée des benchmarks en question (qui sont, au passage, franchement orientés), en tout cas pas pertinente pour contester le fait que que java rende openoffice encore plus lent et lourd:
1 - Ces benchmarks n'évaluent pas le qualificatif de "lourd". Java est lourd (occupe beaucoup plus de mémoire qu'un prog équivalent en C), conteste-tu celà ?. Cette lourdeur / consomation de mémoire affecte les performances sur une machine pesronelle, surtout lorsqu'on a une grosse appli à coté (comme ooffice), qui augmente encore les chances de swapper.
2 - Ces benchmarks n'évaluent pas le temps de chargement (qui comptent beaucoup pour l'utilisateur de suites bureautiques !), seulement le temps de calcul sur des opérations très mathématiques. Et même l'auteur (pourtant très partis pris) en convient dans l'article "Java program startup is slow" .
Ce qui n'est pas un gros pb sur un serveur, où on re-lance rarement les applis, où l'on a généralement assez de mémoire pour tout charger (plugins etc) dès le départ, et où l'on ne charge pas d'énomes toolkits graphiques à la awt/swt/swing; sur un desktop, en revanche, c'est fatal.
gcj permet de compiler un prog java directement en natif, ce qui améliore la rapidité de démarrage
Par contre la rapidité d'execution des pgms compilés avec gcj est catastrophique ...
[^] # Re: Il manque des trucs tout de même
Posté par benp . En réponse à la dépêche OpenOffice 2.0. Évalué à 9.
C'est une utilisation déplacée des benchmarks en question (qui sont, au passage, franchement orientés), en tout cas pas pertinente pour contester le fait que que java rende openoffice encore plus lent et lourd:
1 - Ces benchmarks n'évaluent pas le qualificatif de "lourd". Java est lourd (occupe beaucoup plus de mémoire qu'un prog équivalent en C), conteste-tu celà ?. Cette lourdeur / consomation de mémoire affecte les performances sur une machine pesronelle, surtout lorsqu'on a une grosse appli à coté (comme ooffice), qui augmente encore les chances de swapper.
2 - Ces benchmarks n'évaluent pas le temps de chargement (qui comptent beaucoup pour l'utilisateur de suites bureautiques !), seulement le temps de calcul sur des opérations très mathématiques. Et même l'auteur (pourtant très partis pris) en convient dans l'article "Java program startup is slow" .
Ce qui n'est pas un gros pb sur un serveur, où on re-lance rarement les applis, où l'on a généralement assez de mémoire pour tout charger (plugins etc) dès le départ, et où l'on ne charge pas d'énomes toolkits graphiques à la awt/swt/swing; sur un desktop, en revanche, c'est fatal.
gcj permet de compiler un prog java directement en natif, ce qui améliore la rapidité de démarrage
Par contre la rapidité d'execution des pgms compilés avec gcj est catastrophique ...