Является ли memcpy() обычно быстрее, чем strcpy() (на большинстве реальных платформ)? (Я предполагаю, что размер строки известен.)
Если я правильно помню ассемблер i386, есть loop инструкции, которые копируют заданное количество байтов или слов. Так что это самый быстрый способ, в то время как strcpy() реализация ассемблера i386 будет использовать ручную проверку '\0' в простом цикле.
Так что я чувствую, что на x86 memcpy() быстрее, чем strcpy().
А как насчет других архитектур?
Если вы знаете размер копируемых данных, то memcpy() должно быть таким же быстрым или быстрее, чем strcpy(). В противном случае memcpy() нельзя использовать отдельно, а strcpy() должно быть таким же быстрым или быстрее, чем strlen(), за которым следует memcpy().
Тем не мение...
Многие реализации memcpy() и/или strcpy() и/или strlen() предназначены для эффективной обработки больших объемов данных. Это часто означает дополнительные накладные расходы при запуске (например, определение выравнивания, настройка SIMD, управление кешем и т. д.) и делает эти реализации плохими (медленными) для копирования небольших объемов данных (что гораздо более вероятно в хорошо написанном коде). Из-за этого «должно быть так же быстро или быстрее» не обязательно означает «так же быстро или быстрее». Например, для небольших объемов данных memcpy(), оптимизированный для больших объемов данных, может быть значительно медленнее, чем strcpy(), не оптимизированный для больших объемов данных.
Также обратите внимание, что основная проблема здесь заключается в том, что общий код (например, memcpy() и strcpy()) не может быть оптимизирован для конкретного случая. Лучшим решением было бы иметь несколько функций, например. memcpy_small(), оптимизированный для копирования небольших объемов данных, и memcpy_large(), оптимизированный для плохого кода, который не удалось избежать копирования большого объема данных.
strcpy должен избегать чтения на другой странице после конца строки и должен загружать + проверять некоторые исходные данные, прежде чем он сможет даже выбрать маленькую или большую стратегию. Реализации Glibc довольно хорошо оптимизированы для обоих, с быстрым путем, который хорошо работает для небольших. (Небольшие дополнительные накладные расходы при запуске менее значительны для больших копий.) Но да, memcpy_large может избежать некоторых условных ветвей, прежде чем перейти к стратегии больших копий. Помогает больше для strcpy!
- person Peter Cordes; 29.08.2018
fork()?), Так что большинство на самом деле не копируется, вообще не изменяйте его и только создавайте список различий, объединяйте оба из них (разделить его на блоки любого размера и отслеживать, какие блоки были изменены), ...
- person Brendan; 06.01.2020
Почти на любой платформе memcpy() будет быстрее, чем strcpy() при копировании одинакового количества байтов. Единственный случай, когда strcpy() или любой из его «безопасных» эквивалентов превзойдет memcpy(), будет, когда максимально допустимый размер строки будет намного больше, чем ее фактический размер. Если у кого-то есть буфер, который может содержать строку длиной до миллиона символов, и кто-то хочет скопировать строку в другой буфер на миллион байт, memcpy() придется скопировать миллион байтов, даже если строка в первом буфере состояла всего из двух символов. символы длинные. Однако функция strcpy() или ее эквиваленты могут выполнять досрочный выход и, вероятно, потребуют меньше времени для копирования двух символов, чем memcpy() для копирования миллиона.
memcpy копировать весь буфер, или вы заранее знаете длину строки (возможно, она хранится отдельно в переменной), и вы можете указать memcpy копировать именно столько.
- person Wyzard; 26.07.2014
memcpy(), ни strcpy() нельзя безопасно использовать, если вы не знаете доступное пространство в целевой области и пространство, используемое в исходной области. Таким образом, вы всегда должны использовать memcpy(), потому что вы всегда должны знать, с какой длиной строки имеете дело.
- person Jonathan Leffler; 26.07.2014
strcpy безопасен, если вы знаете, что буфер назначения не меньше размера исходного буфера, даже если вы не знаете длину фактической строки. (Предполагая, что строка не выходит за конец исходного буфера, в этом случае у вас возникнет проблема еще до вызова strcpy.)
- person Wyzard; 26.07.2014
fgets, конец строки известной длины, полученной с помощью strchr или strstr, и т. д.
- person R.. GitHub STOP HELPING ICE; 26.07.2014
strlen с последующим memcpy, вероятно, сравнимо по производительности с strcpy. Однако для огромных строк чтение строки дважды было бы очень дорого.
- person R.. GitHub STOP HELPING ICE; 26.07.2014
memcpyмного лет назад разбил копию на три части: невыровненный префикс, основную часть и невыровненный суффикс. Это означает, что вопросы выравнивания прозрачны для пользователя, а большая часть копии (основная часть) выполняется с максимальной скоростью выравнивания с использованием полноразмерных (например, 32-битных) передач. - person user3386109 schedule 26.07.2014loop— один из самых медленных способов, его больше никто не использует. Старые реализации libc используютrep movsb, тогда как более новые используют SIMD для ускорения. Почему сложные memcpy/memset лучше? - person phuclv schedule 29.08.2018