Делает ли использование больших библиотек по своей сути более медленным кодом?

Question

У меня есть психологический тик, из-за которого я не хочу использовать большие библиотеки (например, GLib или Boost ) на языках более низкого уровня, таких как C и C ++. На мой взгляд, я думаю:

Ну, в этой библиотеке тысячи человеко-часы вложены в это, и это было созданный людьми, которые знают намного больше о языке, чем я когда-либо буду. Их авторы и фанаты говорят, что библиотеки быстрые и надежные, и функциональность выглядит действительно полезно, и это, безусловно, остановит меня от (плохо) изобретать колеса.

Но, черт возьми, я никогда не буду использовать каждая функция в этой библиотеке. Это слишком большой, и это, вероятно, стало раздутым на протяжении многих лет; это еще один мяч и цепочка моя программа должна перетащить.

The Торвальдс декламация (спорно, хотя оно и есть) точно не поместить мое сердце в покое либо.

Есть ли основания для моего мышления, или я просто неразумный и / или невежественный? Даже если я использую только одну или две функции большой библиотеки, то, связавшись с этой библиотекой, я понесу издержки производительности во время выполнения?

Я уверен, что это тоже зависит от того, что представляет собой конкретная библиотека, но мне, как правило, интересно знать, будут ли большие библиотеки на техническом уровне по своей сути вводить неэффективность.

Я устал от одержимости, бормотания и беспокойства по этому поводу, когда у меня нет технических знаний, чтобы знать, прав я или нет.

Пожалуйста, избавь меня от страданий!

Answer 1

Зависит от того, как работает компоновщик. Некоторые компоновщики ленивы и будут включать весь код в библиотеке. Более эффективные компоновщики будут извлекать только необходимый код из библиотеки. У меня был опыт работы с обоими типами.

Меньшие библиотеки будут меньше беспокоиться о любом типе компоновщика. В худшем случае с небольшой библиотекой - небольшое количество неиспользуемого кода. Многие небольшие библиотеки могут увеличить время сборки. Компромисс будет время сборки против пространства кода.

Интересным тестом компоновщика является классическая Hello World программа:

#include <stdio>
#include <stdlib>
int main(void)
{
  printf("Hello World\n");
  return EXIT_SUCCESS;
}

Функция printf имеет много зависимостей из-за всех форматов, которые ей могут понадобиться. Ленивый, но быстрый компоновщик может включать в себя «стандартную библиотеку» для разрешения всех символов. Более эффективная библиотека будет включать только printf и ее зависимости. Это замедляет работу компоновщика.

Приведенную выше программу можно сравнить с этой, используя puts:

#include <stdio>
#include <stdlib>
int main(void)
{
  puts("Hello World\n");
  return EXIT_SUCCESS;
}

Как правило, версия puts должна быть меньше, чем версия printf, потому что puts не требует форматирования, следовательно, меньше зависимостей. Ленивые линкеры будут генерировать тот же размер кода, что и программа printf.

Таким образом, решения о размере библиотеки больше зависят от компоновщика. Именно эффективность линкера. В случае сомнений многие небольшие библиотеки будут меньше полагаться на эффективность компоновщика, но сделают процесс сборки более сложным и медленным.

Answer 2

«еще один шар и цепь». Действительно?

Или это стабильная, надежная платформа, которая в первую очередь обеспечивает работу вашего приложения?

Учтите, что некоторым людям может понравиться "слишком большая и ... раздутая" библиотека, потому что они используют ее для других проектов и действительно доверяют ей.

На самом деле, они могут не связываться с вашим программным обеспечением именно потому, что вы избегаете использовать очевидную «слишком большую и ... раздутую» библиотеку.

Answer 3

Технически, ответ таков: да, они делают.Однако эти неэффективности очень редко практически важны.Я собираюсь использовать статически скомпилированный язык, такой как C, C ++ или D, здесь.

Когда исполняемый файл загружается в память в современной ОС, адресное пространство просто сопоставляется с ним.Это означает, что, независимо от того, насколько велик exableable, если есть целые блоки кода размером с страницу, которые не используются, они никогда не коснутся физической памяти.Однако вы потеряете адресное пространство, и иногда это может иметь значение для 32-битных систем.

Когда вы ссылаетесь на библиотеку, хороший компоновщик обычно выбрасывает лишние вещи, которые вы не используете,хотя особенно в случае создания шаблонов это не всегда происходит.Таким образом, ваши двоичные файлы могут быть немного больше, чем это строго необходимо.

Если у вас есть код, который вы не используете в большой степени с чередованием кода, который вы используете, вы можете в конечном итоге тратить пространство в кеше вашего процессора.Однако, поскольку строки кэша малы (обычно 64 байта), это редко случается в практически важной степени.

Answer 4

FFTW и ATLAS - две довольно большие библиотеки. Как ни странно, они играют большую роль в самом быстром программном обеспечении в мире, приложениях, оптимизированных для работы на суперкомпьютерах. Нет, использование больших библиотек не делает ваш код медленным, особенно когда альтернатива реализует для вас процедуры FFT или BLAS.

Answer 5

fwiw, я работаю на Microsoft Windows и когда мы собираем Windows; сборки, скомпилированные для SIZE , выполняются быстрее, чем сборки, скомпилированные для SPEED , поскольку вы выполняете меньше ошибок при обращении к странице.

Answer 6

Вы совершенно правы, что беспокоитесь, особенно когда речь идет о повышении. Это не столько из-за того, что кто-то пишет, что они некомпетентны, но и из-за двух проблем.

1. Шаблоны - это просто раздутый код. Это не имело значения 10 лет назад, но в настоящее время процессор намного быстрее, чем доступ к памяти, и эта тенденция сохраняется. Я бы почти сказал, что шаблоны являются устаревшей функцией.

Это не так уж плохо для пользовательского кода, который обычно несколько практичен, но во многих библиотеках все определяется в терминах других шаблонов или шаблонов на нескольких элементах (что означает экспоненциальные взрывы кода шаблона).

Простое добавление в iostream добавляет около 3 МБ (!!!) к вашему коду. Теперь добавьте немного вздора и получите 30 мегабайт кода, если вы просто объявите несколько особенно странных структур данных.

Хуже того, вы даже не можете легко профилировать это. Я могу сказать вам, что разница между написанным мною кодом и кодом из библиотек шаблонов - это DRAMATIC, но для более наивного подхода вы можете подумать, что вы добились худших результатов от простого теста, но затраты на свертывание кода возьмут свое средство в большой реальный мир приложение.

2. Сложность. Когда вы смотрите на вещи в Boost, они все сильно усложняют ваш код. Такие вещи, как умные указатели, функторы, всевозможные сложные вещи. Теперь я не скажу, что это никогда не хорошая идея, но почти все это дорого обходится. Особенно, если вы не совсем понимаете, я имею в виду, что именно он делает.

Но люди в восторге от этого и притворяются, что это как-то связано с «дизайном», поэтому у людей создается впечатление, что именно так вы должны делать все, а не только какие-то чрезвычайно специализированные инструменты, которые следует использовать редко. Если когда-либо.

Answer 7

Спросите себя, какова ваша цель. Это рабочая станция среднего уровня сегодня - нет проблем. Это старое оборудование или даже ограниченная встроенная система, тогда это может быть.

Как говорилось в предыдущих постерах, наличие кода там не очень дорого обходится (это может уменьшить локальность кэшей и увеличить время загрузки).