Bug 190237 – since I emerged gcc-config 1.4, running gcc is UNBELIEVABLY slow

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Felix von Leitner 2007-08-25 21:45:56 UTC]

Since I emerged gcc-config 1.4, running gcc takes a hit of 0.6 seconds.
Just gcc.  No arguments.  It's not actually running the compiler backend, or the assembler or linker.  Just gcc.  "gcc: no input files".  Like that.

It should be like this:

$ time /usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2/gcc
gcc: no input files
/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2/gcc  0.00s user 0.00s system 0% cpu 0.003 total

but it is like this:

$ time gcc
gcc: no input files
gcc  0.55s user 0.08s system 99% cpu 0.626 total

OH MY GOD.  What went through your head when you did this?  Un-fucking-believable.  I did an strace just to find out what is happening when I run gcc, and it's running /bin/sh, gcc-config, /sbin/consoletype (?!?), /bin/stty, /usr/bin/python (you've GOT to be kidding me?!?), /bin/env, portageq, /bin/sh (again?!), /usr/sbin/prelink (?!?!?!?), /bin/awk (WTF is wrong with you people?!), another /bin/awk (can't make this up), and finally, what could have been a symbolic link from the beginning, /usr/x86_64-pc-linux-gnu/gcc-bin/4.1.2/gcc.

This is utterly unacceptable.  I was unhappy with aspects of Gentoo before, but this is ridiculous.  This is so unbelievable that I will blog about it, too.  Not even *BSD ever stepped THIS low.  Even Apple and Microsoft would be ashamed of fucking up this badly.  What kind of machine is the guy using who checked this code in?  A 16-core 3 THz Octium from the future?

Reproducible: Always

Steps to Reproduce:
1. run gcc.
2. observe the unbelievable ridiculous slow-down
3. take pain medication

Actual Results:  
gcc is FUCKING SLOW


Expected Results:  
should return immediately.

This is utterly unacceptable.
You should be ashamed of yourself.

Compiling  my own software, dietlibc, now takes 98% cpu 5:16.84 total
It should take no more than 98% cpu 36.712 total

I'm stunned.
How could you!

That's a solid TEN TIMES slowdown.  For nothing!  NOTHING!

Were you sent from the future to destroy Gentoo?  WTF?!?

[Comment 1 Jakub Moc (RETIRED) 2007-08-25 21:51:46 UTC]

It works just fine here. If you are able to file a proper bug containing useful information to debug your issue, including required information such as emerge --info output, and are able restrain yourself to technical issues there,  then file a new one. Bugzilla is not a place for swearing, screaming, names calling and insulting developers.

Marking INVALID because of the reasons stated above.

[Comment 2 Felix von Leitner 2007-08-26 00:55:50 UTC]

Here's the emerge --info.

Portage 2.1.3.6 (default-linux/amd64/2006.1/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22 x86_64)
=================================================================
System uname: 2.6.22 x86_64 unknown
Gentoo Base System release 1.12.10
Timestamp of tree: Thu, 23 Aug 2007 23:20:01 +0000
dev-lang/python:     2.3.6, 2.4.4-r4
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.61-r1
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17.50.0.18
sys-devel/gcc-config: 1.4.0
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.22-r2
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=athlon64"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -pipe -march=athlon64"
DISTDIR="/usr/portage/distfiles"
FEATURES="distlocks metadata-transfer notitles sfperms strict unmerge-orphans userfetch userpriv"
GENTOO_MIRRORS="http://gentoo.mneisen.org/ http://distfiles.gentoo.org"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="X aac acpi alsa amd64 arts berkdb bitmap-fonts bzlib cairo cdb cdr cli cracklib crypt dbus dri dvb dvd dvdr eds emboss encode esd exif fam firefox flac fortran ftp gdbm gif gmp gnome gpm gstreamer gtk gtk2 gtkhtml hal iconv ipv6 isdnlog jabber jpeg jpeg2k kde kdeenablefinal ldap mad maildir midi mikmod mmap mozilla mp3 mpeg mudflap ncurses netboot nodrm nptl nptlonly offensive ogg oggvorbis opengl openmp oss pam pcre png posix ppds pppd qt3 qt4 quicktime readline reflection sdl session slang sockets speex spell spl ssl theora tiff truetype truetype-fonts type1-fonts unicode vorbis xinerama xml xorg xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i810 mach64 mga neomagic nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY



I'll give you personally ten bucks if this helps you debug the issue.

I told you exactly what the bug is.  The bug is that /usr/bin/gcc is not a symlink to the gcc profile I chose but a binary that calls a giant shell script to find out what gcc profile I chose.  That's a ridiculously superfluous indirection right in the main performance path for Gentoo, because what Gentoo users does all day is emerge stuff, which calls gcc a couple thousand times a day.

I dare you to tell me how the emerge --info helps you.  Do it publicly, please, so the humiliation is greater.

I will give you one more good piece of information:

  $ qfile /usr/bin/gcc
  $

NOBODY OWNS /usr/bin/gcc!  What a great distro you have there.  Debian would be proud of you.

[Comment 3 Jakub Moc (RETIRED) 2007-08-26 01:03:16 UTC]

(In reply to comment #2)
> NOBODY OWNS /usr/bin/gcc!  What a great distro you have there.  Debian would be
> proud of you.

Of course noone owns it, otherwise you couldn't have more than one gcc version installed. That's the whole point of gcc-config, ditto for binutils-config.

Now, either file a new unpoluted bug, stick your straces, emerge --info and other relevant information there and keep your rants and insults out of bugzilla, or don't comment at all, especially if you apparently don't understand how the thing works.

Thanks in advance.

[Comment 4 Felix von Leitner 2007-08-26 01:34:07 UTC]

I am not opening another bug.
I put all the information here.
Fix the bug.

It is everything but clear that noone should own /usr/bin/gcc.
I would have made it owned by gcc-config.

My gcc binary calls a shell script and not gcc.
That shell script is called

  /usr/bin/gcc-config --get-bin-path

This shell script takes up most (all?) of the time because it calls all the other crap.  But hey, since you told me I don't understand how the thing works, I don't need to tell you this, since you obviously do.

The only mystery is why you mark the bug invalid instead of fixing the problem.

But apparently Gentoo is not interested in fixing bugs.  I understand, it's easier to close bugs as "invalid" than to investigate.  Work, work work.
Don't bother.  I'll switch distros.  Don't fix it for me, what do I care how much you make Gentoo suck in the future.

[Comment 5 Jakub Moc (RETIRED) 2007-08-26 01:38:06 UTC]

userrel, all yours...

[Comment 6 Jorge Manuel B. S. Vicetto (RETIRED) 2007-08-26 02:23:35 UTC]

Hi.

As Jakub was trying to tell you, a different attitude when reporting a bug can make a huge difference on the way it's treated. Please try to be less "colourful".
I have an amd64 here and as you can see I don't get slow responses from gcc.

user@host ~ $ time gcc
gcc: no input files

real	0m0.086s
user	0m0.000s
sys	0m0.003s

user@host ~ $ time gcc
gcc: no input files

real	0m0.002s
user	0m0.000s
sys	0m0.002s

I'm going to attach my emerge --info and the strace of gcc.

[Comment 7 Jorge Manuel B. S. Vicetto (RETIRED) 2007-08-26 02:24:55 UTC]

Created attachment 129197 [details]
gcc strace

[Comment 8 Jorge Manuel B. S. Vicetto (RETIRED) 2007-08-26 02:26:12 UTC]

Created attachment 129199 [details]
emerge --info

[Comment 9 Jorge Manuel B. S. Vicetto (RETIRED) 2007-08-26 02:35:57 UTC]

Please post the output of the following:

gcc-config -l
gcc-config -E
gcc-config -B
gcc-config -L
ls -l /etc/env.d/gcc
cat /etc/env.d/gcc/config-x86_64-pc-linux-gnu
cat /etc/env.d/gcc/x86_64-pc-linux-gnu*

I'm also cc'ing the gcc maintainer and the toolchain herd in case they want to comment.

[Comment 10 Felix von Leitner 2007-08-26 02:39:28 UTC]

% which gcc
/usr/bin/gcc
%

Apparently the default bash path puts the real gcc in the path before /usr/bin.
I wouldn't know because I don't use bash.

This whole construct is braindead.  gcc-config should make /usr/bin/gcc a symlink, not a "let's run this huge shell script using python and awk" binary.

[Comment 11 SpanKY 2007-08-26 02:49:07 UTC]

no point in pursing this further as the reporter isnt worth working with

we'll handle this in a different bug