On Sat, Apr 28, 2012 at 12:24 PM, Philipp Thomas <Philipp.Thomas2@gmx.net> wrote:
On Fri, 27 Apr 2012 20:24:32 -0700, Jeff Janes <jeff.janes@gmail.com> wrote:
The difference in performance is erased by setting LANG=C (the default is en_US.UTF-8), which change makes the installed binary much faster but doesn't change the built-from-source binary performance. See examples below.
That's to be expected. Many distributions (I know of at least Fedora and Arch Linux besides SUSE) use a patch that teaches the coreutils how to handle multibyte locales. The downside is that multibyte processing slows down the utils.
OK, thanks. I think there might be a way to only suffer the slow down if the delimiter is actually a wide character (sort, for example, doesn't seem to be slowed down when the input happens to have no wide characters), but I don't know how to go about doing that. I'll probably just set LANG=C in my login rc file and call it a day.
Is it a known issue that building from source lets the CPU safely take advantage of short-cuts to make things faster even under UTF-8 that a packaged binary cannot? Or perhaps is there a bug in the build-from-source that makes it faster, but somehow unsafe for UTF-8?
Something's wrong if you get different results from a binary package vs. binaries built by building your owen rpm.
If you do not use our spec file and the patches we supply it's no wonder you get faster binaries. So the real question is, how did you build the binaries precisely.
I built it from the instructions from INSTALL file that came in the tarball put in /usr/src/packages/SOURCES by running zypper install -t srcpackage coreutils. So I guess I did the wrong thing there.
If you built the package locally by using build, there should be no differences.
OK, thanks. I haven't been able to get build to work for me yet, I'll keep trying. Thanks, Jeff -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org