Какой использовать - memmove () или memcpy () - когда буферы не накладываются?
Другое решение для вашего конкретного примера:
Предположим, что:
-
/aдля класса ресурсов -
/b/cи/b- пути для методов
, поскольку полный путь выглядит следующим образом:
Используйте необязательный параметр
@Path("/b{c : (/c)?}")
public Response searchNames(@PathParam("c") String val) {
...
}
Пример выше работает для всех примеров, таких как:
-
/b -
/b/ -
/b/c -
/b/c/
, но если c предоставлен, val - /c (перед ним есть /).
Если вы хотите решить проблему выше (чтобы избежать разбора Java), вам нужно что-то более сложное:
@Path("/b{slash : (/)?}{c:((?<=/).*)?}")
, который вернет только c (не /c) для 3-я маркерная точка, но для четвертой маркерной точки она вернет c/, которая должна быть проанализирована на Java.
Но для вашего случая ( "выполненный метод один и тот же" ), не беспокойтесь о разборе, потому что у вас нет разных действий.
4 ответа
Если предположить, что реализация вменяемой библиотеки, memcpy всегда будет как минимум так же быстр, как memmove. Однако, на большинстве платформ разница будет минимальной, и на многих платформах memcpy является лишь псевдонимом для memmove для поддержки устаревшего кода, который (некорректно) вызывает memcpy на перекрывающихся буферах.
Как memcpy, так и memmove должны быть написаны, чтобы воспользоваться самыми быстрыми загрузками и хранилищами, доступными на платформе.
Чтобы ответить на вопрос: следует использовать тот, который семантически корректен. Если вы можете гарантировать, что буферы не перекрываются, используйте memcpy. Если вы не можете гарантировать, что буферы не перекрываются, используйте memmove.
memcpy() не имеет специальной обработки для перекрывающихся буферов, поэтому в нем отсутствуют некоторые проверки, поэтому он быстрее, чем memmove().
Также на некоторых архитектурах memcpy() может быть полезно использование инструкций ЦП для перемещения блоков памяти - то, что memmove() не может использовать.
На некоторой платформе ARM, над которой я сейчас работаю, memmove работал в 3 раза быстрее чем memcpy для короткой не выровненной загрузки. Поскольку memcpy и memmove являются единственным действительно переносимым механизмом перетаскивания типов, вы могли бы подумать, что компилятор проверит их перед попыткой использовать NEON для этого.
Если вас интересует, какая подстрока будет работать лучше, нужно протестировать ее на целевой платформе. Ничто в стандарте не задает, как реализуются функции, и, хотя может показаться логичным, что неконтролируемый memcpy будет быстрее, это отнюдь не определено.
Вполне возможно, хотя и маловероятно, что человек, написавший для вашего конкретного компилятора memmove был дипломированным гением, в то время как бедная душа, получившая работу по написанию memcpy, была деревенским идиотом :-)
Хотя на самом деле мне трудно представить, что memmove мог быть быстрее memcpy, я не сбрасываю со счетов эту возможность. Measure, don't guess.