Journal Compresser Firefox...

Posté par Pinaraf le 10 juin 2004 à 19:13.

Étiquettes :

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 Pinaraf le 10 juin 2004 à 19:27. É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 Jazz le 10 juin 2004 à 20:45. É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 Pinaraf le 10 juin 2004 à 20:54. É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 Jazz le 10 juin 2004 à 23:30. É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 Pinaraf le 11 juin 2004 à 12:52. É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 shinobufan (site web personnel) le 10 juin 2004 à 20:04. É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 Pinaraf le 10 juin 2004 à 20:38. É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 shinobufan (site web personnel) le 10 juin 2004 à 20:51. É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 -=[ silmaril ]=- (site web personnel) le 10 juin 2004 à 21:27. É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 shinobufan (site web personnel) le 10 juin 2004 à 21:38. É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 djapat le 11 juin 2004 à 00:42. É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 mickabouille le 11 juin 2004 à 10:50. É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 Pinaraf le 11 juin 2004 à 12:14. É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 Pinaraf le 10 juin 2004 à 20:31. É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 Pinaraf le 10 juin 2004 à 20:41. É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 Pinaraf le 10 juin 2004 à 21:41. É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 zebul666 le 11 juin 2004 à 13:17. É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 ?
- [^] # Re: upx --compress-icons=0 *.dll
  
  Posté par Pinaraf le 11 juin 2004 à 17:54. Évalué à 1.
  
  Comment marche prelink ? Que fait-il exactement ? Pourquoi seul root peut l'utiliser ?

Suivre le flux des commentaires

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