Discussion :

[DindonSauvage]

Bonjour,

Aujourd'hui, on parle beaucoup de utorrent à cause de son rachat par bitTorrent. J'ai utilisé longuement ce logiciel et j'ai toujours été agréablement surpris par sa faible taille, sa rapidité, sa faible consommation CPU et mémoire et malgré tout ça il avait en plus un grand nombre de fonctionnalités.
Du coup, je me suis retrouvé à aller consulter le lien wikipedia de utorrent (http://fr.wikipedia.org/wiki/Utorrent) et j'y ai lu ça :

Composé d'un seul fichier exécutable de 170 Kilo-octet (aucune installation n'est requise), μTorrent est un client extrêmement compact. Cette petite taille a pu être atteinte en évitant d'utiliser des bibliothèques massives (telle que la bibliothèque C++ standard et le stream facilities) et en créant des substituts écrits spécialement pour ce programme. Le fichier exécutable est également compressé à un ratio de 50% en utilisant PECompact.

J'ai été assez surpris d'apprendre que la bibliothèque standard avait pour défaut de faire des logiciels "lourds". En plus, quelle bibliothèque les concepteurs ont-ils utilisé pour limiter le poids de leur logiciel? Ont-ils seulement utilisé le C++? Est-ce que la bibliothèque standard provoque aussi une perte de performance ou/et une grosse utilisation mémoire? qu'est-ce que le stream facilities?

En fait, j'aimerais comprendre quelles sont les méthodes les plus adaptées pour écrire un logiciel le moins lourd (qui prend le moins de ressources CPU, mémoire et disque) et le plus rapide possible (là, je pense que je suis un peu redondant parce qu'un programme rapide doit automatiquement utiliser moins de ressource CPU qu'un moins rapide...).
Quels sont les langages et les bibliothèques les plus adpatés à l'écriture d'un programme "léger"? (Sans parler de l'assembleur...)

[Caine]

Le problème des bibliothèques C++/C et des compilateurs c'est que même si tu n'utilises qu'une fonction de la bibliothèque, le linker te la remonte en entier.

C'était du moins vrai à une époque. Je crois (sans garanti) que ça c'est amélioré.

Par définition, les flux, les fonctions génériques...sont plus lourdes en conséquences (cpu, mémoire) que le code spécifique. Mais elles ont l'avantage par contre (lorsque c'est bien utiliser) de réduire la taille de l'exécutable.

Après, à moins que l'auteur ne donne les infos, ça va être dur de savoir comment il a fait.

Ca impressionne

[Lunixinclar]

En fait, j'aimerais comprendre quelles sont les méthodes les plus adaptées pour écrire un logiciel le moins lourd (qui prend le moins de ressources CPU, mémoire et disque) et le plus rapide possible.

C'est principalement une question d' algorithme. J'ai vu des programmes VB tourner plus vite que les mêmes en C ou en assembleur. L' optimisation de la taille de l' exe vient après.

Ceci dit c'est vrai que les fonctions standard ne sont pas forcément les plus rapides. Je passe la moitié de mon temps à les mesurer, l' autre moitié à les ré-écrire. Résultat: des vitesses jusqu'à 12 fois supérieures.

En C, l'intégralité de la lib n'est pas incluse, mais le header, oui. C'est très simple: quand on écrit #include <stdio.h> le préprocesseur ne réfléchit pas et se borne à copier/coller le contenu du fichier stdio.h exactement comme s'il était écrit dans le programme. Et substitue les macros, qui dupliquent le code rendant le code plus gros... Ensuite seules les fonctions utilisées sont effectivement incluses à l' édition de liens.

Pour avoir de bonnes performances il faut partir d'un bon algorithme, puis faire du profilage de code, pour identifier les parties les plus couteuses. En général un programme passe 90% de son temps sur une seule partie du code. Celle-là mérite alors d'être écrite en assembleur.

[hegros]

quelle bibliothèque les concepteurs ont-ils utilisé pour limiter le poids de leur logiciel?

Je ne sais pas exactement ce que tu entends par poid du logiciel mais une technique consiste à utiliser des library partagées(dll/ISO) et à régler comme il faut les options d'optimisations dans ton EDI.