Journal Compresser Firefox...

Posté par  .
Étiquettes : aucune
0
10
juin
2004
Bonjour journal...

Aujourd'hui, je présente à tout le monde mon petit script écrit à la va-vite ce matin sur du papier brouillon : il me permet de faire passer une installation de firefox 0.9Rc1 (mais ça marche aussi avec les nightly) de 19,1Mo à 10,2Mo en 1 minute 9 secondes sur mon athlon 2000+
Comme ça, je suis moins jaloux du travail fait sur la version win dont l'installeur ne pèse que 4,6Mo ;)
J'espère que vous trouverez des améliorations à y apporter !
Notamment, comment faire pour vérifier la présence d'un fichier ? Et quels autres fichiers puis-je compresser ?
Voici le script :

#!/bin/sh

export ff_dir="firefox-test"
cd $ff_dir
echo "UPX..."
upx --best firefox-bin
upx --best mozilla-xremote-client
upx --best xpicleanup
upx --best components/talkback/talkback
echo "JAR..."
cd chrome
for i in *.jar;
do
mkdir temp;
mv $i temp/$i;
cd temp;
unzip $i;
rm -f $i;
zip -r -9 $i *;
cp $i ../;
cd ..;
rm -fr temp;
done;

Il faut indiquer au début du script l'emplacement de firefox.
Je prépare la même chose pour l'installeur...
En espérant que ce script vous sera utile...
  • # Premier changement

    Posté par  . Évalué à 1.

    J'ai trouvé moi même une réponse à ma question comment savoir si un fichier existe... Voici donc une petite modification à faire au script :
    remplacer la ligne upx --best components/talkback/talkback par
    if [ -a "components/talkback/talkback" ] ; then
    upx --best components/talkback/talkback;
    fi
    Comme ça ceux qui ont pas installé ce composant n'auront pas de problèmes...
    • [^] # Re: Premier changement

      Posté par  . Évalué à 1.

      if [ -a "components/talkback/talkback" ] ; then

      Je pense que c'est plutôt ceci que tu veux:
      if [ -f "components/talkback/talkback" ] ; then

      -a, c'est le ET logique.
      • [^] # Re: Premier changement

        Posté par  . Évalué à 1.

        J'ai lu cette info dans la page de man de bash et ça marche apparemment... Au début j'essayais avec -f (qui me semble plus logique) et ça marchait pas.
        • [^] # Re: Premier changement

          Posté par  . Évalué à 3.

          En effet, sous bash, -a marche. Mais seulement si sh est en réalité bash. Mieux vaut alors remplacer #!/bin/sh par #!/bin/bash. Sinon, man test.

          Celà dit, bizarre que -f ne fontionne pas pour toi...
          • [^] # Re: Premier changement

            Posté par  . Évalué à 1.

            Si en fait -f marche, hier j'avais du faire une faute de frappe...
            Les scripts corrigés sont sur mon site...
  • # Un peu HS, désolé....

    Posté par  (site Web personnel) . Évalué à 6.

    Ce journal me donne l'occasion de poser une question que je me suis déjà posé y'a un moment : pourquoi les distributions linux n'utilisent-t-elles pas plus souvent upx pour compresser les exécutables les plus imposants, genre > 500ko ? Les paquets seraient ansi moins gros à télécharger, comme pour le cas de firefox ici, puisque upx compresse beaucoup plus les binaires que tar.gz & co. De nombreux Mo seraient gagnés mine de rien.

    En plus sur les machines récentes le temps de chargement supplémentaire du à upx est à priori négligeable... Cela dit, vous me direz qu'avec l'internet rapide et les gros disques actuels on se moque de la taille des binaires...

    Enfin voila, c'était ma question existentielle du jour (suis pas très inspiré en ce moment ^^)
    • [^] # Re: Un peu HS, désolé....

      Posté par  . Évalué à 2.

      Cela serait particulièrement intéressant pour un liveCd !
      Mais bon, upx (avec l'option --best) reste lent à compacter donc ça enlève l'envie de compresser 1Go de programmes... Voici les résultats sur l'exécutable de firefox (sur mon Athlon XP2000+ toujours...)
      [pierre@localhost firefox-base]$ time upx --best firefox-bin
      Ultimate Packer for eXecutables
      Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002
      UPX 1.24 Markus F.X.J. Oberhumer & Laszlo Molnar Nov 7th 2002

      File size Ratio Format Name
      -------------------- ------ ----------- -----------
      9749588 -> 4055109 41.59% linux/386 firefox-bin

      Packed 1 file.
      41.23user 0.48system 0:48.83elapsed 85%CPU (0avgtext+0avgdata 0maxresident)k
      0inputs+0outputs (0major+25735minor)pagefaults 0swaps

      48 secondes pour compresser 9,8Mo c'est plutôt chiant si le nombre de paquets est trop élevé...
      • [^] # Re: Un peu HS, désolé....

        Posté par  (site Web personnel) . Évalué à 2.

        Oui c'est clair vu comme ça ca parait un peu pénible... Mais ajouté au fur et à mesure aux scripts de génération de paquets (quelque soit leur format et la distrib concernée ^^) ca ne serait rien. 48 secondes après je sais pas combien de minutes (heures ?) de compilation...

        Mais si ce n'est pas fait, c'est qu'il soit y avoir une raison. Je ne sais pas laquelle par contre !?
        • [^] # Re: Un peu HS, désolé....

          Posté par  (site Web personnel) . Évalué à 1.

          Peut etre (et meme surement) qu'en plus de ralentir la creation de packages, ca va ralentir l'execution des programmes.
          • [^] # Re: Un peu HS, désolé....

            Posté par  (site Web personnel) . Évalué à 2.

            Justement, j'avais cru comprendre qu'après la décompression qui s'effectue au chargement du binaire en mémoire, le programme ne souffrait d'aucun ralentissement puisqu'il est déjà complètement décompressé, ni même de surconsommation mémoire ni rien du tout o_O Alors ou est la faille ? ;)
            • [^] # Re: Un peu HS, désolé....

              Posté par  . Évalué à 2.

              Le fait de devoir décompresser consomera du cpu au chargement pour le décomprésser... et le fait que c'est compressé POURRAIT demander moi de temps de chargement (lecture du fichier sur le disque) étant donné que le fichier est plus petit.

              L'avantage premier est le gain en espace dique et il se peut que le temps de le temps de chargement + le temps de décompréssion soit bénéfique ou pénalisant: tout dépend du cpu (486 33Mhz ou p4 3000Mhz), du disque (vieux ide ou scsi) et du taux de compression du programme...
    • [^] # Re: Un peu HS, désolé....

      Posté par  . Évalué à 2.

      > Les paquets seraient ansi moins gros à télécharger, comme pour le cas de firefox ici, puisque upx compresse
      > beaucoup plus les binaires que tar.gz & co.
      Ça change la taille une fois sur ton ordinateur, pas la taille du fuchier que tu télécharges avant de l'installer. Si celui qui fait le paquet fournit un /usr/bin/firefox compressé comme ça dans son .tgz (ou .deb, .rpm), la taille du paquet sera en gros la même que s'il ne le compresse pas (parce que faut pas rêver, un algo de compression marche toujours moins bien sur des données compressées).
      • [^] # Re: Un peu HS, désolé....

        Posté par  . Évalué à 0.

        Tu as tout à fait raison !
        Démonstration avec firefox : je compresse tout avec upx, je recompresse en tar.gz. Résultat : gain de 200Ko sur la version compressée contre 9Mo sur la version non compressée...
  • # Compression de l'installeur

    Posté par  . Évalué à 1.

    Les gains sont vraiment moins importants...
    (perfs sur l'installeur : la dernière nightly passe de 8,1 à 7,9 Mo : ridicule quoi...)
    Le script pour l'installeur est dispo sur :
    http://www.pinaraf.xalp.org/compact_installer.sh(...)
    Le script pour un dossier installé de firefox sur :
    http://www.pinaraf.xalp.org/compact_firefox.sh(...)

    Toute remarque est la bienvenue
    • [^] # Re: Compression de l'installeur

      Posté par  . Évalué à 0.

      J'oubliais de préciser : un installeur ainsi modifié produit un firefox comme modifié par l'autre script...
      (je pense que c'était pas assez clair)
  • # Résultats sur firefox 0.8 fr

    Posté par  . Évalué à 1.

    Là aussi les résultats sont très bons : on passe de 26,2 à 13,7Mo (plugins + extensions installés et fonctionnels après compactage...)
    Où puis-je proposer mes scripts sur mozilla.org ?
  • # upx --compress-icons=0 *.dll

    Posté par  . Évalué à 1.

    t'es pas le seul à avoir eu cette idée.

    Je l'utilisais pour mozilla <1.2 et qui mettait des plombes sans compression à charger surtout sur mon pauvre celeron de l'époque et de mon pauvre dd.

    avec upx , tu peux compresser les dll sous "fenetre" et ca mettait 5 fois moins de temps a charger surtout que mon dd avait beaucoup de ko à lire ...

    c'est utiliser par exemple par mame je crois.

    Je trouvais par contre beaucoup moins efficasse le même traitement pour la version linux

    Je suppose que maintenat ce qu'il faut utiliser c'est le prelink. Non ?
    Ca doit donner des resultats aussi interessant en terme de temps de chargement ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.