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" ?
>> Par ailleurs, comment as-tu vérifié la taille de mon fichier, en décompressé? >> > J'ai décompressé le fichier et demandé la taille du dossier obtenu à mon > explorateur de fichiers. > Je ne sais pas comment MacOS traite les associations fichier <-> > application mais sous Linux/gnome il suffit de faire click droit sur le > nom du fichier dans Nautilus (l'explorateur de fichiers) puis choisir > "extraire ici" et tu obtiens un dossier du même nom que le fichier. Ici > Nautilus est capable de se rendre compte que, même si le fichier n'a pas > l'extension zip, c'est quand même une archive et il propose donc la > possibilité de le décompresser. Pour faire pareil sous MS-Windows il > faut renommer le fichier en .zip. Honnêtement, je ne sais pas trop. Je crois qu'il y a une base de données quelque part qui associe les fichiers aux programmes, mais des exceptions peuvent être enregistrées pour chaque fichier, probablement dans l'autre branche du "fork", que tout fichier enregistré sur système de fichier HFS+ indique. C'est très souple, mais pour me simplifier la vie, je met l'extension qui correspond à l'application qui doit l'ouvrir. >> 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. 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. Je suis d'accord que beaucoup de RAM soit une bonne solution, mais je suis contre la fuite en avant, qui s'apparente à une capitulation, et devra de toute manière prendre fin à court terme, la plupart des portables étant limités à la présence de 4Gio de RAM, le prix des barrettes 4Gio ayant de quoi en arrêter plus d'un. La puissance CPU, à l'inverse, croît toujours rapidement, et à terme, je pense qu'il serait plus économique de solliciter davantage le CPU que le disque dur. > Une autre approche pourrait être de reconsidérer l'organisation de tes > documents en remettant en question le rassemblement dans un seul > document d'autant de feuilles. Est-ce bien nécessaire ? Peut-être que > lier des fichiers entre eux serait plus efficace. Si on ne travaille pas > sur toutes les feuilles en même temps pourquoi les mettre toutes dans le > même document ? Quand j'ai commencé le travail en créant ce document, la liaison entre documents dans OOo n'était pas supportée de la même façon sous Linux (au labo), Windows (au bureau) et Mac (à la maison). Rassembler toutes ces feuilles était donc le seul moyen fiable de traiter ces données et de détecter rapidement la moindre erreur de classement. Par ailleurs, l'échantillon expérimental d'où proviennent ces données est relativement restreint (environ 300), et la question reste donc posée; comment doit-on procéder dans OOo, alors que l'utilisation de MS Office dans ce contexte ne poserait aucune contrainte particulière? Par ailleurs, au risque de sembler sévère avec l'équipe de développement de OOo, si MS Office parvient à manier ces fichiers sans peine, OOo doit en être capable également, ou faire mieux. La structure du XML n'est pas une excuse; je crois que MS Office 2008, dans son propre format basé sur le XML, ne consomme pas davantage qu'avec la version XLS. OOo a donc des inefficacités dont il faut se débarrasser pour qu'il soit l'égal de MS Office pour les grosses charges. Comme tu le signes, « > Seuls des formats ouverts peuvent assurer la pérennité de vos documents. » 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. 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. 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. Patrick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
