Создание маленьких haskell исполняемых файлов?
Для меня я предпочитаю использовать второе решение, оно более тонкое, или вы можете использовать мой пример чуть ниже:
using (var sqlConnection = new SqlConnection(connection))
{
using (var command = new SqlCommand(query, sqlConnection))
{
using (var read = command.ExecuteReader())
{
// process on your read
}
}
}
7 ответов
С веткой разработки GHC (кто-нибудь знает, в какой именно версии это было добавлено?):
$ ghc -o hello hello.hs
$ strip -p --strip-unneeded --remove-section=.comment -o hello-small hello
$ du hello hello-small
700 hello
476 hello-small
Добавьте флаг -dynamic для динамически связанной RTS:
$ ghc -dynamic -o hello hello.hs
$ strip -p --strip-unneeded --remove-section=.comment -o hello-small hello
$ du hello hello-small
24 hello
16 hello-small
См. Также: http: // hackage .haskell.org / trac / ghc / wiki / SharedLibraries / PlatformSupport
Для сравнения с C:
$ gcc hello.c -o hello
$ strip -p --strip-unneeded --remove-section=.comment -o hello-small hello
$ du hello hello-small
12 hello
8 hello-small
GHC статически связывает все (кроме библиотек, пользовавшихся самим временем выполнения, которые связаны динамично).
В старости GHC связал целую (haskell) библиотеку в том, как только Вы использовали что-то от него. Когда-то назад GHC начал связываться "на obj файл", который решительно уменьшил двоичный размер. Судя по размеру, Вы уже, должно быть, использовали более новый GHC.
Зато, у Вас уже есть много материала в тех 500K, как многопоточное ядро, сборщик "мусора" и т.д.
Добавьте, по крайней мере, сборщик "мусора" к своему коду C, затем сравните их снова :)
Необходимо ли считать благословения (370 КБ? Luuuxury):
bash$ sbcl This is SBCL 1.0.24, an implementation of ANSI Common Lisp. * (sb-ext:save-lisp-and-die "my.core") [undoing binding stack and other enclosing state... done] [saving current Lisp image into ./my.core: ... done] bash$ du -sh my.core 25M my.core bash$
Серьезно, хотя, в то время как можно, вероятно, вытряхнуть haskell двоичные файлы немного, это - действительно не справедливое сравнение с C. Там существует больше продолжения.
В прошлый раз я играл с ghc (и это могло бы устареть), он статически связывал все, которое будет фактором.
Размер, который Вы видите, является временем выполнения Haskell (libHSrts.a), который статически связан в каждый исполняемый файл Haskell. Если бы это был общий объект, как librt.o для C, то Ваш двоичный файл был бы только несколькими k (размер разделения.o файл в источнике библиотеки).
За исключением реализации динамического подключения libHSrts.a на Вашей платформе, можно сделать исполняемые файлы меньшими через полосу.
strip -p --strip-unneeded --remove-section=.comment -o your_executable_small your_executable
также попытайтесь смотреть на ldd - доктор your_executable
Вещи меняются - следите за этой продолжающейся работой.
Если размер вашего двоичного файла действительно имеет значение, вы можете использовать инструмент gzexe , который упаковывает (предпочтительно уже удаленный) исполняемый файл с помощью сжатия gzip. На моем 64-битном Linux-сервере исходная программа hello world занимает 552 КБ после удаления 393 КБ и 125 КБ после удаления и сжатия. Более темная сторона gzip-архивирования заключается в производительности - сначала необходимо распаковать исполняемый файл.