• [^] # Re: N'est stupide que la stupidité :)

    Posté par (site web personnel) . En réponse à la dépêche Go-oo, une alternative à OpenOffice. Évalué à 4.

    1°) Les SGBD aussi, les interfaces d'utilisations des sgbd aussi.
    Alors montre moi un foutu soft qui embarque un SGBD et une IHM qui me permette d'ouvrir un CSV aussi simplement que le permet Excel.

    2°) C'est clair que tout le monde est équipé de la dernière version d'une suite payante et uniquement sur certains os ... surtout sur un site comme linuxfr, ou en entreprise.
    On s'en fou, le but est de montrer qu'un tableur est pas forcement un mauvais condidat pour ouvrir un CSV. Pas de ma faute si OOo n'est pas aussi performant.

    et tous tes exemples c'est 'excel sait (peut être) le faire donc c'est forcément génial. La preuve : il sait ouvrir un document statique de 1 millions de lignes!".
    L'exemple initial c'était avec 32000 lignes. Y'a forcement une limite au tableur, mais le fait est que cet ordre de grandeur est tout à faire raisonnable pour un tableur "moderne" et "performant".

    1°) tu as pas répondu à la question. A tu vraiment fait le test ? Si oui, comment a tu fait pour ne pas faire preuve de la moindre curiosité pour savoir ce qui n'allait pas sur ton pc/pour ooo pendant 20 minutes! C'est long 20 minutes, et ca m'étonne beaucoup que tu n'ai rien vu
    oui j'ai fais le test évidemment, mais le premier "bug" que je vois, et il est énorme, c'est ce "freeze" utilisateur. Excel quand j'ai essayé avec 10 millions de lignes, il m'a juste fait comprendre que c'était trop gros dans un joli message.
    Pour info le CPU montait à 100% mais la RAM n'avait pas l'air d'augmenter.

    2°) Donc tu veux pas savoir "pourquoi il n'y arrive pas", mais tu arrive a dire directement que ce n'est pas un problème de ressources.
    Mais je sais très bien pourquoi il y arrive pas : il est pas conçu pour y arriver. J'arrive effectivement à affirmer que ce n'est pas un problème de ressources au sens où Excel y arrive sur la même machine avec les mêmes ressources à disposition (CPU, RAM, disque). La limitation est donc bien interne à OOo.

    ie : si il "suffit" de rajouter 2 Go pour que ca puisse marcher, c'est pas que OOo sait pas le faire, mais qu'il gère mal la mémoire, ce qui a juste rien à voir
    En supposant une mémoire mal gérée, ca reste un problème purement interne à OOo et pas de ressources externes.

    C'est bien ce que tu me dis non ?
    Tout ce que j'essai de démontrer, c'est que pour les volumétries qui nous intéresses, le CPU, la RAM et l'espace disque d'une machine "standard" (1 Go de ram, 2 Ghz, 100Go de dur), un tableur "conçu" pour ce scénario n'a aucun problème et que donc un tableur peut être tout à fait aproprié.

    4°) De plus, sachant que rien que lancer OOo ou autre prend fastoche 30 secondes sur la plupart des pc utilisé (entreprise ou particulier), j'émets quelques doutes sur ton "24 secondes".
    mon scénario ests exécuté une fois l'appli lancée (fichier, ouvrir)

    5°) Enfin, ouvrir un document de 1M lignes statiques consitue bien un test de volumétrie, mais n'est certainement pas le seul test que l'on puisse effectuer.
    As tu essayer en
    -> sauvant au format natif et le ré ouvrant ?

    Notre problématique c'est : est-ce que un tableur est aproprié pour ouvrir un CSV de plus de 32000 lignes ?