gcc - 内置的grep比Linux随附的grep慢

Question

我试图理解为什么我构建的grep比系统随附的grep慢得多，并试图找到系统随附的grep使用了哪些编译器选项。

操作系统版本：CentOS版本5.3（最终版）
grep在系统上：

版本：grep（GNU grep）2.5.1
大小：88896字节
ldd输出：
libpcre.so.0 => /lib64/libpcre.so.0（0x0000003991800000）
libc.so.6 => /lib64/libc.so.6（0x0000003985a00000）
/lib64/ld-linux-x86-64.so.2（0x0000003984a00000）


我建立的grep：

版本：2.5.1
大小：256437字节
ldd输出：
libpcre.so.0 => /lib64/libpcre.so.0（0x0000003991800000）
libc.so.6 => /lib64/libc.so.6（0x0000003985a00000）
/lib64/ld-linux-x86-64.so.2（0x0000003984a00000）


在大型列表文本文件上运行正则表达式搜索时，系统grep（330毫秒）的性能比我构建的grep（22430毫秒）要快得多。

以下是我以前定时的命令..

％time src / grep“。* asa。*” large_list.txt> / dev / null
真正的0m22.430s
用户0m22.291s
sys 0m0.080s


要么

％时间bin / grep“。* asa。*” large_list.txt> / dev / null
真正的0m0.331s
用户0m0.236s
sys 0m0.081s


系统grep显然正在使用一些优化选项，这些选项带来了巨大的性能差异。

某些机构可以帮助我构建grep的哪些选项吗？

这是我构建..时源文件之一的编译选项。
gcc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I. -I.. -I.. -I. -I../intl -g -O2 -MT xstrtol.o -MD -MP -MF .deps/xstrtol.Tpo -c -o xstrtol.o xstrtol.c

./configure的输出：

正在检查与BSD兼容的安装... / usr / bin / install -c
检查构建环境是否正常...是
检查线程安全的mkdir -p ... / bin / mkdir -p
检查gawk ... gawk
检查make set $（MAKE）...是
检查构建系统类型... x86_64-unknown-linux-gnu
检查主机系统类型... x86_64-unknown-linux-gnu
检查gawk ...（已缓存）gawk
正在检查gcc ... gcc
检查C编译器的默认输出文件名... a.out
检查C编译器是否工作...是
检查我们是否在交叉编译...否
检查可执行文件的后缀...
检查目标文件的后缀... o
检查我们是否正在使用GNU C编译器...是
检查gcc是否接受-g ...是
正在检查gcc选项以接受ISO C89 ...不需要
检查make所使用的include样式... GNU
检查gcc的依赖项样式... gcc3
正在检查与BSD兼容的安装... / usr / bin / install -c
检查ranlib ... ranlib
正在检查getconf ... getconf
正在检查CFLAGS值以请求大文件支持...
正在检查LDFLAGS值以请求大文件支持...
正在检查LIBS值以请求大文件支持...
正在检查_FILE_OFFSET_BITS ...否
正在检查_LARGEFILE_SOURCE ...否
正在检查_LARGE_FILES ...否
检查功能原型...是
检查如何运行C预处理程序... gcc -E
检查处理长行的grep和-e ... / bin / grep
正在检查egrep ... / bin / grep -E
检查ANSI C标头文件...是
正在检查sys / types.h ...是
正在检查sys / stat.h ...是
正在检查stdlib.h ...是
正在检查string.h ...是
正在检查内存...是...
正在检查strings.h ...是的
正在检查inttypes.h ...是
正在检查stdint.h ...是
检查unistd.h ...是的
检查string.h ...（已缓存）是
正在检查size_t ...是
正在检查ssize_t ...是
正在检查符合ANSI C的常量...是
正在检查inttypes.h ...是
正在检查未签名的长久...是的
检查ANSI C头文件...（缓存）是
检查string.h ...（已缓存）是
正在检查stdlib.h ...（已缓存）是
正在检查sys / param.h可用性...是
检查sys / param.h是否存在...是
正在检查sys / param.h ...是
正在检查memory.h ...（已缓存）是
检查unistd.h ...（已缓存）是
正在检查libintl.h可用性...是
检查libintl.h存在...是
正在检查libintl.h ...是
检查wctype.h可用性...是
检查wctype.h存在...是
正在检查wctype.h ...是
检查wchar.h可用性...是
检查wchar.h存在...是
正在检查wchar.h ...是
检查定义DIR的dirent.h是
正在检查包含opendir的库...不需要
检查统计文件模式宏是否损坏...否
检查工作的alloca.h ...是的
检查分配...是
检查closedir是否返回void ...否
正在检查stdlib.h ...（已缓存）是
检查unistd.h ...（已缓存）是
正在检查getpagesize ...是
检查工作mmap ...是
正在检查btowc ...是
正在检查isascii ...是
正在检查iswctype ...是
正在检查mbrlen ...是
正在检查记忆...是的
正在检查设置模式...否
检查是否有错误...是
正在检查wcrtomb ...是的
正在检查wcscoll ...是
正在检查wctype ...是
检查mbrtowc和mbstate_t是否正确声明...是
正在检查stdlib.h ...（已缓存）是
正在检查mbstate_t ...是
正在检查内存...是的
正在检查stpcpy ...是
正在检查strtoul ...是的
检查atexit ...是
正在检查fnmatch ...是
正在检查stdlib.h ...（已缓存）是
检查是否将strtoumax定义为宏...否
检查strtoumax ...是的
检查是否声明strtoul ...是
检查是否声明strtoull ...是
正在检查-lcposix中的错误...否
检查内联...内联
正在检查off_t ...是
检查我们是否正在使用GNU C Library 2.1或更高版本...是
正在检查argz.h可用性...是
检查argz.h存在...是
正在检查argz.h ...是
正在检查limits.h可用性...是
正在检查limits.h是否存在...是
正在检查限制。h...是
检查locale.h可用性...是
正在检查locale.h存在...是
正在检查语言环境。
正在检查nl_types.h可用性...是
正在检查nl_types.h是否存在...是
正在检查nl_types.h ...是
检查malloc.h可用性...是
检查malloc.h是否存在...是
检查malloc.h ...是
正在检查stddef.h可用性...是
检查stddef.h存在...是
正在检查stddef.h ...是
正在检查stdlib.h ...（已缓存）是
检查string.h ...（已缓存）是
检查unistd.h ...（已缓存）是
检查sys / param.h ...（已缓存）是
正在检查feof_unlocked ...是
检查fgets_unlocked ...是
正在检查getcwd ...是的
检查getegid ...是的
正在检查geteuid ...是的
正在检查getgid ...是的
检查getuid ...是的
检查mempcpy ...是
检查munmap ...是的
检查是否有腐臭...是的
正在检查设置...是
正在检查setlocale ...是
正在检查stpcpy ...（已缓存）是
检查strchr ...是的
正在检查strcasecmp ...是
检查strdup ...是的
检查strtoul ...（已缓存）是
正在检查搜索...是的
检查__argz_count ...是
检查__argz_stringify ...是
检查__argz_next ...是
正在检查图标...是
正在检查iconv声明...
extern size_t iconv（iconv_t cd，char * * inbuf，size_t * inbytesleft，char * * outbuf，size_t * outbytesleft）;
正在检查nl_langinfo和CODESET ...是
正在检查LC_MESSAGES ...是
检查是否要求NLS ...是
检查是否要求包含gettext ...否
检查libintl.h ...（已缓存）是
检查libc中的GNU gettext ...是
正在检查dcgettext ...是
正在检查msgfmt ... / usr / bin / msgfmt
正在检查gmsgfmt ... / usr / bin / msgfmt
检查xgettext ... / usr / bin / xgettext
检查野牛...野牛
正在检查野牛的版本... 2.3，还可以
正在检查要安装的目录... af be bg ca cs da de eo es et eu fi fr ga gl he hr hu id it ja ko ky lt nb nl pl pt pt_BR ro ru rw sk sl sr sv tr uk vi zh_TW
检查dos文件约定...否
检查主机系统类型...（已缓存）x86_64-unknown-linux-gnu
检查主机系统类型...（已缓存）x86_64-unknown-linux-gnu
正在检查DJGPP环境...否
检查环境变量分隔符...：
检查工作的re_compile_pattern ...是
正在检查getopt_long ...是
配置：警告：包含的lib / regex.c未使用
检查是否声明了strerror_r ...是
正在检查strerror_r ...是
检查strerror_r是否返回char * ...否
检查是否有错误...（已缓存）是
检查strerror_r ...（缓存）是
正在检查vprintf ...是
检查doprnt ...否
检查ANSI C头文件...（缓存）是
检查工作分配器...是的
检查工作重新分配...是
正在-lpcre中检查pcre_exec ...是
配置：创建./config.status
config.status：创建Makefile
config.status：创建lib / Makefile
config.status：创建lib / posix / Makefile
config.status：创建src / Makefile
config.status：创建测试/ Makefile
config.status：创建po / Makefile.in
config.status：创建intl / Makefile
config.status：警告：intl / Makefile.in似乎忽略了--datarootdir设置
config.status：创建doc / Makefile
config.status：创建m4 / Makefile
config.status：创建vms / Makefile
config.status：创建引导程序/ Makefile
config.status：创建config.h
config.status：config.h不变
config.status：执行depfiles命令
config.status：执行default-1命令
config.status：创建po / POTFILES
config.status：创建po / Makefile
config.status：执行stamp-h命令


谢谢，
库马尔

Answer 1

您为什么不只为grep二进制文件获得CentOS的SRPM，然后将它们的编译选项与您的选项进行比较？我想这比整个StackOverflow社区在黑暗中盲目戳戳直到碰到东西要有效得多。
编辑：您正在使用多字节编码的语言环境吗？ （注意：如果您不知道这是什么意思，那么答案可能是“是”，因为UTF-8多年来一直是大多数Linux发行版的默认版本，而RedHat（因此是CentOS）确实是第一个这样做的人。进行切换）。
在这种情况下，GNU grep速度很慢。这不仅适用于GNU grep，而且几乎适用于所有进行某种文本处理的GNU工具。 FSF拒绝接受任何补丁以提高多字节性能，除非事实证明这些补丁不会降低固定宽度的编码速度。但是，由于任何要提高多字节编码性能的补丁都必须至少在某处包含一些if语句，因此实际上不可能编写一个补丁，该补丁至少不会降低固定宽度编码的速度，至少不会降低该if的开销。 >声明。因此，GNU工具的UTF-8性能将一直持续到时间结束。
无论如何，大多数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发行的GNU grep。多字节编码中的文本处理永远不会比固定宽度编码中的文本处理快，但是它至少应该是可比的，而不是慢50倍（甚至有人报告的1500倍）慢。
还有另一个名为dfa-optional的补丁程序，它使grep仅仅使用GNU libc的regex引擎而不是它自己的regex引擎，这不仅在处理UTF-8时快得多，而且错误少得多。
因此，您可能需要重新设置export LC_ALL=POSIX来运行基准测试。如果这样可以解决您的问题，则需要应用上述两个补丁之一。
这两个RedHat错误报告中也提供了更多信息：

Bug 69900 - grep writing output very slow
Bug 121313 - grep SLOW on multibyte LC_CTYPE

故事的寓意：尽管人们普遍认为，Linux发行商至少在某些时候确实知道他们在做什么。不要对它们进行第二次猜测。