#include v / s performance

Question

(я определил эту программу в терминах программы на C ++, потому что я сталкивался с этим при кодировании программы на C ++, но на самом деле вопрос не зависит от языка).

Мне пришлось копировать символы из одного символа *буфер в другой буфер.Итак, вместо того, чтобы делать #include <cstring> для strcpy, я сам написал небольшой фрагмент кода, чтобы сделать то же самое.

Вот мысли, о которых я мог подумать тогда:

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

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

Answer 1

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

Но да, если бы мне пришлось включить целую библиотеку boost дляодиночная функция, я бы попытался скопировать ее непосредственно из библиотеки: -)

Я добавлю, что вопрос помечен как «независимый от языка», поэтому мы не можем просто говорить о разнице между C/ Заголовки C ++ и библиотеки C / C ++.Если мы говорим о родовом языке, включение внешней библиотеки МОЖЕТ иметь побочные эффекты, даже БОЛЬШИЕ побочные эффекты.Например, это может очень сильно замедлить запуск вашей программы, даже если она не используется (потому что она имеет статические инициализаторы, которые должны вызываться при запуске, или она ссылается на скопления других библиотек dll / dynamic, которые необходимо загрузить),И это не первый раз, когда возникает ошибка при запуске программы, вызванная статическим запуском одной из ее зависимостей :-)

Так что в конце концов "это зависит".Я бы сказал, что если нужно скопировать только один файл (скажем, 250-500 строк) из источника BSD, то здесь нет больших проблем, для чего, возможно, потребуется более крупная ссылка на библиотеку.

Answer 2

Когда вы говорите о производительности, что вы хотите оптимизировать? Время компиляции, размер двоичного файла / объекта, скорость выполнения?

Использование стандартной библиотеки имеет большое преимущество для улучшения кода Поддерживаемость и Читаемость . Если кому-то еще нужно пересмотреть или изменить ваш код, гораздо лучше использовать «стандартный» способ.

Гораздо проще обнаружить ошибку при вызове memcpy () или strncpy (), чем при вызове MyMemCpy () или MyStringCpy ()

Answer 3

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

Приличный компоновщик должен собирать только те куски, которые ему действительно нужны.