Bonjour JB, Le 09/01/10 à 18:05, Jean-Baptiste Faure a écrit :
> Re-bonjour Patrick, > 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? >>> >> 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. 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! 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 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. ;-) 1Gio était insuffisant dans la machine du labo sous Windows avec OOo 3.0; il crashait. Avec 3Gio et Ubuntu, OOo 3.0 avait toute les peines du monde à l'enregistrer, mais au moins restait stable. OOo 3.0 était bien moins optimisé question consommation, il est vrai. Une licence étudiante de MS Office 2007 est en ce moment très abordable, à 80$, il y a une méchante promotion. Impossible d'avoir 4Gio de DDR3 SODIMM pour ce prix. Il n'en reste que le faible coût (relatif) de la RAM ne doit pas être une excuse au gaspillage de ressources. Apparemment, les programmeurs ne sont pas de mon avis, à voir la tendance inflationniste de conso par les applications, qui empêche, à toutes fins pratiques, d'être aussi efficace qu'on le pourrait en cas de multi-tâche. Par exemple, en 99, j'arrivais à faire tourner parfaitement Napster, 10 téléchargements et 5 sites chargés, graphiquement, dans Internet Explorer avec seulement 64Mio de RAM et sans swapper des quantités déraisonnables. Dix ans après, j'ai de la chance si j'arrive à télécharger 10 fichier autour d'un serveur eMule (pas Kad, qui consomme) et ouvrir 5 onglets de FF sur des sites statiques sans consommer 500Mio de RAM. Pourtant, les tâches effectuées sont les mêmes, et la charge demandée, censé être identique. >> 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. Même fonctionnement sous OS X. Mais même un bon OS ne peut rien quand l'application "réclame" toujours plus de RAM et se comporte comme si elle tournait seule. La RAM est faite pour être utilisée, mais le swap doit être banni, autant que possible. Pas d'autre solution que de réduire la consommation de RAM, pour atteindre ce but. >> 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. Sinon, quelle alternative pour le scientifique désirant travailler avec des ensembles lourds de données ET en formats pérenne? > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
