Y a-t-il une solution simple : Pourquoi est-GHC si grand ?
Pas intéressé dans l’évangélisation de « Pourquoi je ne devrais pas préoccuper la taille si Haskell est l’outil » ; Il s’agit d’une question technique.
C'est un peu idiot, vraiment. Chaque bibliothèque qui vient avec GHC est fourni dans pas moins de 4 saveurs:
Le GHCi version est la version statique de liens dans un seul .o le fichier. Les trois autres versions ont tous leur propre jeu de fichiers d'interface (.hi fichiers). Le profilé de versions semblent être environ deux fois la taille de la unprofiled versions (ce qui est un peu suspect, je devrais regarder pourquoi).
Rappelez-vous que GHC est lui-même une bibliothèque, de sorte que vous obtenez 4 copies de GHC. Non seulement cela, mais le GHC binaire lui-même est lié statiquement, de sorte que 5 exemplaires de GHC.
Récemment, nous avons fait en sorte que GHCi pourrait utiliser la statique .a fichiers. Qui va nous permettre de se débarrasser de l'une de ces saveurs. À plus long terme, nous devons lier dynamiquement GHC, mais c'est un grand changement parce que cela reviendrait à faire la liaison dynamique par défaut - contrairement au C, avec GHC vous avez à décider d'avance si vous allez à se lier dynamiquement ou non. Et nous avons besoin de plus de changements (par exemple, à la Cabale et le système de paquets, parmi d'autres choses) avant de ce qui est vraiment très pratique.
Sans doute nous faut comparer des pommes avec des pommes et des oranges les oranges. JRE est un moteur d'exécution, pas un kit de développement. Nous pouvons comparer: source: la taille de la trousse de développement, la taille de la compilation du kit de développement et la compilation de la taille de l'exécution minimale.
OpenJDK 7 de la source de faisceau est de 82 MO (download.java.net/openjdk/jdk7) vs GHC 7 source bundle, qui est de 23 MO (haskell.org/ghc/download_ghc_7_0_1). GHC n'est pas grand ici. Runtime taille: openjdk-6-jre-headless sur Ubuntu est de 77 MO décompressé vs Haskell helloworld, statiquement lié à son exécution, qui est <1 MB. GHC n'est pas grand ici.
Où GHC est gros, c'est la taille de la compilation du kit de développement:
GHC lui-même prend 270 MO, et avec toutes les bibliothèques et utilitaires livrés ensemble, il prend plus de 500 MO. Et oui, c'est beaucoup, même avec des librairies de base et un outil de construction/dependency manager. Java plate-forme de développement est plus petit.
GHC:
$ aptitude show ghc6 | grep Size
Uncompressed Size: 388M
contre OpenJDK withdependencies:
$ aptitude show openjdk-6-jdk openjdk-6-jre openjdk-6-jre-headless ant maven2 ivy | grep Size
Uncompressed Size: 34.9M
Uncompressed Size: 905k
Uncompressed Size: 77.3M
Uncompressed Size: 1,585k
Uncompressed Size: 3,736k
Uncompressed Size: 991k
Mais il est encore plus de 100 MO, pas de 26 MO comme vous l'écrivez.
Poids lourd de choses dans ghc6 et ghc6-prof:
$ dpkg -L ghc6 | grep '\.a$' | xargs ls -1ks | sort -k 1 -n -r | head -3
57048 /usr/lib/ghc-6.12.1/ghc-6.12.1/libHSghc-6.12.1.a
22668 /usr/lib/ghc-6.12.1/Cabal-1.8.0.2/libHSCabal-1.8.0.2.a
21468 /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0.a
$ dpkg -L ghc6-prof | grep '\.a$' | xargs ls -1ks | sort -k 1 -n -r | head -3
112596 /usr/lib/ghc-6.12.1/ghc-6.12.1/libHSghc-6.12.1_p.a
33536 /usr/lib/ghc-6.12.1/Cabal-1.8.0.2/libHSCabal-1.8.0.2_p.a
31724 /usr/lib/ghc-6.12.1/base-4.2.0.0/libHSbase-4.2.0.0_p.a
Veuillez noter quelle est la taille de libHSghc-6.12.1_p.a. La réponse semble donc être la liaison statique et le profilage des versions pour chaque bibliothèque.
Ma conjecture--beaucoup, beaucoup de liaison statique. Chaque bibliothèque a besoin de lier statiquement ses dépendances, qui à son tour besoin de lier statiquement leur et soforth. Et c’est tout souvent compilé avec et sans profilage et même sans le profilage les binaires ne sont pas dépouillés et donc contenir beaucoup d’informations du débogueur.
Voici l'annuaire la taille de ventilation sur ma boîte:
https://spreadsheets.google.com/ccc?key=0AveoXImmNnZ6dDlQeHY2MmxPcEYzYkpweEtDSS1fUlE&hl=en
Il regarde comme le plus grand répertoire (123 MO) est le binaires pour la compilation du compilateur lui-même. Les documents à peser dans une étonnante 65 MO. La troisième place est Cabale à 41 MB.
Le répertoire bin de 33 MO, et je pense que seul un sous-ensemble de qui est ce qui est techniquement nécessaire pour construire Haskell applications.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
