Почему бы вам просто не получить SRPM от CentOS для двоичного файла grep и сравнить их параметры компиляции с вашими? Я предполагаю, что это гораздо эффективнее, чем когда все сообщество StackOverflow слепо копается в темноте, пока не наткнется на что-либо.
EDIT: вы используете локаль с многобайтовой кодировкой? (Примечание: если вы не знаете, что это значит, то ответ, вероятно, «Да», поскольку UTF-8 по умолчанию используется большинством дистрибутивов Linux уже несколько лет, и действительно RedHat (и, следовательно, CentOS) были первыми сделать переключатель).
В этом случае GNU grep будет медленным. И это относится не только к GNU grep, но и практически ко всем инструментам GNU, которые выполняют какую-то обработку текста. FSF отказывается принимать какие-либо исправления для улучшения многобайтовой производительности, если не доказано, что эти исправления не замедляют кодирование с фиксированной шириной. Однако, поскольку любой патч для повышения производительности для многобайтовых кодировок должен , по крайней мере, содержать где-нибудь оператор if, на самом деле невозможно написать патч, который по крайней мере не замедляет фиксированный кодирование по крайней мере на издержки этого оператора if. Таким образом, производительность UTF-8 инструментов GNU будет продолжать отстой до конца времени.
В любом случае, большинство дистрибьюторов Linux не дают крысам бип , что думает FSF, и все равно исправляют GNU grep. Fedora Rawhide SRPM содержит патч grep-2.5.3-egf-speedup.patch, который ускоряет работу GNU grep на UTF-8 на несколько порядков. (Поскольку этот патч уже выпущен в 2005 году, я предполагаю, что он также используется в CentOS.) Этот патч также используется в Mac OSX, Debian, Ubuntu, ..., почти никто не использует GNU grep, распространяемый GNU. Обработка текста в многобайтовой кодировке никогда не будет такой быстрой, как в кодировке с фиксированной шириной, но она должна быть, по крайней мере, сопоставимой, а не в 50 раз (или даже в 1500 раз, как сообщали некоторые люди) медленнее.
Есть также еще один патч под названием dfa-optional, который заставляет grep просто использовать движок регулярных выражений GNU libc вместо своего собственного, который не только на намного быстрее при работе с UTF-8 но также имеет гораздо меньше ошибок.
Итак, вы можете перезапустить тесты с установленным export LC_ALL=POSIX. Если это решит вашу проблему, вам нужно применить один из двух вышеупомянутых патчей.
Дополнительная информация также доступна в этих двух отчетах об ошибках RedHat:
Мораль этой истории: несмотря на распространенное мнение, дистрибьюторы Linux do знают, что они делают, по крайней мере иногда. Не угадывайте их.