Re-bonjour Patrick, Le 09.01.2010 22:42, PAt a écrit : > Bonjour Jean-Baptiste, > > Le 09/01/10 à 15:48, Jean-Baptiste Faure a écrit : > >>> Y a-t-il quelque chose de prévu pour optimiser le rendu des fichiers XML en >>> n'interprétant pas tout ce qui n'est pas nécessaire à la feuille affichée? >>> >>> >> En quelque sorte. Par exemple il y a eu des modifs sur la 3.2 pour >> l'étape d'adaptation des hauteurs de lignes lors du chargement d'un >> fichier. En gros les hauteurs de ligne ne sont recalculées que quand >> c'est nécessaire. >> > Si c'est implémenté dans la m8, je n'ai pas remarqué grande différence dans > le temps d'ouverture du fichier. Concrètement, à quoi correspondant ce calcul > de "hauteur de ligne" ? > L'adaptation dynamique de la hauteur des lignes en fonction de leurs contraintes de formatage et de leur contenu. > ..................... >>> Avec une telle consommation et sachant que normalement, je dois ouvrir deux >>> fichiers lourds de ce type pour travailler, on comprend facilement que la >>> RAM disponible devient le facteur limitant. De l'optimisation (en ne >>> chargeant pas les parties inutiles) serait bienvenue pour les travailleurs >>> "lourds". >>> >> Oui mais ce que tu vas gagner en RAM tu vas le perdre en temps CPU et >> accès disque puisqu'il faudra lire et écrire sur le disque pour ne >> garder en mémoire que ce qui est nécessaire. Ce genre de chose est >> normalement géré par l'OS lui-même qui swape quand il en a besoin. De >> toute façon la seule solution pour traiter efficacement de gros fichiers >> est d'avoir beaucoup de RAM. >> > J'inclus la swap dans la mémoire totale, comme l'OS. Si l'application en > question ne charge que ce qui est nécessaire, le reste n'est tout simplement > pas interprété / décompressé, et reste dans cet état dans la RAM, et ne peut > prendre plus de taille que le fichier sur le disque dur. > Comment fais-tu pour savoir si une partie du fichier est nécessaire ou non sans tout charger et interpréter dés le début ? > Même avec la gestion du swap la plus efficace possible comme on l'a sous Mac > OS X et Linux, swapper reste en soi une mauvaise chose, puisque la > performance du plus performant des disques durs mécaniques, même des SSD, > reste à des lieues de celle de la RAM. > Réduire la consommation de RAM est donc le plus sûr moyen de réduire celle de > swap, et par ricochet, d'améliorer la performance générale de l'application. > Oui mais c'est une course perpétuelle en ce que l'utilisateur demande au logiciel et les ressources machine disponible, plus il y a de ressources plus on charge le logiciel. Mais il y a un moment où il faut ajouter de la RAM à l'ordinateur. Pourquoi ce qui est normal quand on joue avec des images ne l'est pas quand on utilise un tableur ? As-tu déjà essayé d'afficher une image jpeg de 40 Mo ? Si tu n'as pas une machine avec au moins 2 Go de RAM tu n'y arriveras pas. Là tu as plus de 2.000.000 de cellules soit environ 39.000 pages imprimées (d'après les stats de OOo). Il est normal qu'il faille beaucoup de RAM pour traiter tout ça. Et encore je trouve qu'il se comporte plutôt bien, oui c'est long mais ça marche sans planter ni bloquer OOo. J'ai vu des fichiers avec beaucoup moins de données mais nettement plus de formules pour lesquels c'était bien pire.
Cela étant il demeure vrai qu'il faut améliorer les performances de OOo sur le chargement et l'enregistrement. C'est un des points sur lequel travaille le projet performance. Il y a par exemple des travaux sur un enregistrement incrémental mais je ne sais pas où ça en est ni comment ça peut fonctionner. Quant à comparer avec XL, je maintiens que le xml est une des causes du temps de chargement et qu'il faudrait comparer au chargement par XL 2007 d'un fichier équivalent en OOXML et non au format xls. Si le format de chaque onglet était de type CSV (en gros une matrice) je suis convaincu que le chargement serait nettement plus rapide. Mais cela engendrerait d'autres difficultés. > ................. > C'est bien avec cette intention que j'ai amassé les données de mon projet > dans ces formats, mais s'il n'y a pas d'application capable de les lire à un > coût (financier ou de performance) abordable, cet avantage est caduc. > Il faut alors comparer le prix d'une barrette de 1 Go de RAM et celui d'une licence MS-Office 2007 Pro. ;-) > Ce qui me préoccupe est que, malgré leur poids, ces fichiers ne font > pratiquement aucun calcul, et que je suis loin de la limite théorique de OOo. > Même quand le format OpenDocument est utilisé à faible capacité (dans OOo), > comme ici, la consommation frôle l'inacceptable. > La consommation de RAM n'a pas vraiment d'importance tant que ça passe, la mémoire est faite pour être utilisée. C'est à l'OS à la gérer au mieux pour obtenir les meilleures performances. Sous Linux la RAM est toujours pleine, d'abord avec les programmes en cours d'utilisation et ensuite, s'il reste de la place, avec le cache disque. > On ne peut pas se contenter d'avoir un format pérenne et se contenter d'une > application-phare "juste suffisante". Il faut faire mieux. > D'accord avec toi mais pour ça nous avons besoin de plus de développeurs capables et ayant envie de s'attaquer au problème. Et il est vrai que le traitement de données scientifiques nombreuses avec OOo n'est pas, pour le moment, le cœur de cible de Sun donc de la plupart des développeurs de OOo. Bonne soirée JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
