Bonjour, Le 10.01.2010 01:01, PAt a écrit : > .............. >> L'adaptation dynamique de la hauteur des lignes en fonction de leurs >> contraintes de formatage et de leur contenu. >> > Ce n'est pas une information enregistrée directement dans le fichier? > Je sais qu'il y a beaucoup de "trous" dans la spécification OpenDocument, > est-il possible d'avoir cette information enregistrée afin qu'elle ne soit > pas calculée à chaque ouverture, de manière standard, bien sûr? > On peut toujours faire ce genre de chose j'imagine, mais ce n'est pas OpenOffice.org qui décide du format ODF même si son influence sur ODF est importante. Je ne sais pas ce qu'il en est actuellement. >>> 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 ? >> > Je ne suis pas programmeur, mais instinctivement je dirais: précharger les > noms des feuilles et la première feuille en entier; considérant le paradigme > de OOo qui veut que l'on attribue un style à toute mise en forme, et donc, > par extension, que l'on soit ordonné dans sa manière de procéder, > l'utilisateur devrait cliquer sur la feuille qui l'intéresse, qui serait > chargée au moment de son appel, mais pas avant. > Et inversement, décharger la feuille de la mémoire (RAM et swap) sitôt > qu'elle n'est plus nécessaire. > Là tu auras des conflits avec les utilisateurs qui veulent que l'accès aux données soient rapide. Charger et décharger les feuilles non utilisées consomment du temps. Une des difficultés est de trouver un compromis.
> Pour gérer les feuilles liées entre elles, on pourrait avoir une option pour > actualiser la feuille courante automatiquement, par intervalles, qui bien sûr > augmenterait beaucoup la consommation ponctuellement, mais permettrait > d'économiser les ressources de la machine le reste du temps. > > J'ignore s'il y a eu quelque progrès en ce sens dans le noyau OOo, mais > lorsque NeoO est en arrière-plan depuis quelque temps, il libère de la RAM > dont les autres applications peuvent bénéficier. > > Ou la procédure inverse: tout charger au départ, puis décharger > automatiquement ce qui "semble" ne pas être immédiatement nécessaire à > l'utilisateur. Il y a des algorithmes pour ça. > > >>> 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. >> > Je n'ai jamais prétendu qu'ouvrir une image non compressée (donc, aucune > donnée additionnelle à "recréer") de 40 Mio sature une machine de 1Gio de RAM > soit normal ! Mais je ne peux pas aborder sur la liste toutes les questions > d'informatique, ce n'est pas l'endroit! > Ce n'est pas ça. Une image jpeg de 40 Mo fait environ 20 fois plus en RAM car c'est un format compressé. Tu as donc un problème analogue à celui de OOo : manipuler un objet énorme qui occupe une partie importante de la RAM ou même plus que la RAM disponible. > La question en reste une de comparaison: le XML tel qu'utilisé dans OOo > semble inefficace par rapport au XLS utilisé dans MS Office, pour les mêmes 2 > millions de cellules. > > >> 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. >> > Je sais que NeoO est capable d'enregistrer dans le format XLSX, mais il me > faudrait la contribution de quelqu'un pour le tester sous XL 2007 ou 2008. > > Devrais-je produire des versions XLSX et XML pour Office 2003, afin que qqn > compare? > Si comparer t'intéresse effectivement il faudrait produire un fichier xlsx puis l'utiliser avec XL-2007 ou suivant. > ................. >>> 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. >> > Quelle est la cible, exactement? Je suis bien conscient des limites du > développement open-source, et dans beaucoup de cas, bénévole. > Bien entendu il n'y a pas explicitement de cible mais il me parait clair que l'utilisateur "standard" visé manipule plutôt des données comptables et financières. Rien de gigantesque et dés que ça devient lourd on passe sur des outils logiciels dédiés. Mais je me trompe peut-être. > Sinon, quelle alternative pour le scientifique désirant travailler avec des > ensembles lourds de données ET en formats pérenne? > Sous Linux il faudrait essayer Scilab, R, et LabPlot. Ils ne sont pas équivalents et ne te permettront pas de travailler comme tu le fais avec OOo mais ils permettent de manipuler des données, faire des calculs et produire des graphiques, au besoin en programmant dans leur langage propre. R est spécialisé dans les statistiques. Ce sont des outils standards pour les labos de recherche. Je ne sais pas non plus si LabPlot supporte la même charge que OOo mais il permet une manipulation des données de type tableur. Il y a sans doute d'autres logiciels que je ne connais pas. Bonne journé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]
