Many projects like software from cr.yp.to or most of my projects consist of hundreds of small files. Since upgrading gentoo installed gcc-config on my system, gcc performance has been reduced to about one tenth, which makes me feel like I'm working on my old Pentium 90 again. When I first noticed this, I tried unmerging gcc-config, which broke the whole system. I vote to remove gcc-config. Its performance is absolutely unbearable (and for what? A simple symbolic link would have been sufficient). Also, I don't see the point of this. Only software developers might need more than one gcc version (I certainly don't). Running one python instance for every gcc run is not acceptable. Reproducible: Always Steps to Reproduce: 1. run gcc often. 2. 3. Actual Results: gcc appears to be _really_ slow. Expected Results: not run python for each gcc run. gcc already is a wrapper. No need to wrap it one more time. BTW: man gcc, gcc -V 3.1.1 does what gcc-config purports to offer.
What makes you think python is involved? gcc-config's wrappers are written in C...
file /usr/bin/gcc-config /usr/bin/gcc-config: a /bin/bash script text executable
gcc-config is run a single time - to set your gcc profile. The /usr/bin/gcc wrapper takes over after that and gcc-config doesn't need to be called again, AFAIK...
Hi Felix. Would you mind backing up your assertion with some hard data? As far as I can tell, the gcc-config program is not run each time gcc is called. For example: $ time gcc-config --get-bin-path /usr/i686-pc-linux-gnu/gcc-bin/3.2 real 0m0.287s (admittedly very slow) $ time gcc -c t.c real 0m0.021s (apparently not calling gcc-config) No offense intended, but so far this looks like a non-bug to me, so I'm marking it RESOLVED INVALID until some evidence is provided. Please REOPEN the bug when you have provided some additional information. (Of course Azarah might reopen this bug himself if he disagrees with me... ;-)
I am fine with this. It will only be slow if you did not source /etc/profile, but that is because then it needs to call gcc-config to figure out where gcc's binaries are. But this is a config that you would only maybe have after just bootstrapping and compiling the kernel, and could have been prevented by sourcing /etc/profile.
$ strace -fF -eopen /usr/bin/gcc -v execve("/usr/bin/gcc", ["/usr/bin/gcc"], [/* 64 vars */]) = 0 [pid 21954] execve("/bin/sh", ["sh", "-c", "/usr/bin/gcc-config --get-bin-pa"...], [/* 64 vars */]) = 0 [pid 21954] execve("/usr/bin/gcc-config", ["/usr/bin/gcc-config", "--get-bin-path"], [/* 63 vars */]) = 0 [pid 21956] execve("/bin/stty", ["stty", "size"], [/* 63 vars */]) = 0 [pid 21959] execve("/usr/bin/which", ["which", "which"], [/* 63 vars */]) = 0 [pid 21961] execve("/usr/bin/python", ["/usr/bin/python", "-c", "import portage; print portage.se"...], [/* 63 vars */]) = 0 [pid 21962] execve("/bin/bash", ["[] bash", "-c", "/usr/sbin/prelink --version > /d"...], [/* 92 vars */]) = 0 [pid 21963] execve("/usr/sbin/prelink", ["/usr/sbin/prelink", "--version"], [/* 92 vars */]) = -1 ENOENT (No such file or directory) execve("/usr/i686-pc-linux-gnu/gcc-bin/3.2/gcc", ["/usr/i686-pc-linux-gnu/gcc-bin/3"...], [/* 64 vars */]) = 0 Also, I can see the python processes in ps when I compile something. Also: $ man gcc-config No manual entry for gcc-config $ There is not even documentation on how to turn this crap off.
I see it now. I can reproduce this with: $ PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin $ time gcc -c t.c real 0m0.300s whereas when my shell has started, portions of the PATH are set in /etc/profile: $ echo $PATH /usr/local/home/agriffis/bin:/usr/local/bin:/usr/local/sbin:/usr/bin/mme:/usr/bi n:/bin:/usr/sbin:/sbin:/usr/dt/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/bin/X11/demo s:/usr/bin/mtools:/usr/ucb:/etc:/usr/etc:/usr/games:/opt/bin:/usr/i686-pc-linux- gnu/gcc-bin/3.2:/opt/Acrobat5:/opt/blackdown-jre-1.4.1/bin:/usr/qt/3/bin $ time gcc -c t.c real 0m0.022s Is this a suitable solution to the problem for you? I realize that gcc-config is pretty slow, and you have a good point about not many people needing to have more than one compiler installed. But it seems to me that the system isn't as bad as it sounded at first. My suspicion is that your .bash_profile or .bashrc (assuming that you use bash) is completely overriding the PATH instead of inheriting it from /etc/profile. Some people would solve this by doing: PATH=mystuff:$PATH or PATH=$PATH:mystuff Personally I don't like this solution because you end up with duplicates in the PATH. I'll attach a couple functions I use for PATH manipulation in my .bashrc which keep things tidy for me.
Created attachment 10221 [details] bash PATH manipulation functions
Created attachment 10224 [details, diff] gcc-config patch Here's a different approach to the problem. This patch keeps gcc-config from calling Python except when it actually needs to. Azarah, hows does this look to you?
Right, like I said, his environment is not updated. Unfortunately you cannot make everything 100% fool proof if no knowledge exist, or heed is taken regarding standard env/shell practices. It does give help if you run without arguments (default if man foo do not give man page ?). ------------------------------------------------------------ # gcc-config Usage: gcc-config [Option] [CC Profile] Change the current cc/gcc profile, or give info about profiles. Options: --use-old Use the old profile if one was selected. --use-portage-chost Only set to given profile if its CHOST is the same as that set for portage in /etc/make.conf (or one of other portage config files...). --get-current-profile Print current used gcc profile. --list-profiles Print a list of available profiles. --print-environ Print environment that can be used to setup things for current gcc profile, or specified one ... --get-bin-path Print path where binaries of given/current profile are located. --get-lib-path Print path where libraries of given/current profile are located. --get-stdcxx-incdir Print path to g++ include files of given/current profile. The profile name is in the form of: <CHOST>-<gcc version> For example: i686-pc-linux-gnu-3.2.1
Aron, looks good, but would you mind doing the changes against gcc-config-1.3.1 with CVS revision 1.2 ? Should take care of the extra fluff that is in there from the diff with rev 1.1 ..
*** Bug 18881 has been marked as a duplicate of this bug. ***
Created attachment 10331 [details, diff] new gcc-config patch Sorry about that, I didn't notice it the first time.
Thanks, in gcc-config-1.3.2.
Ok, you might want to try gcc-config-1.3.3 ... it tries to figure out where gcc are if PATH is not setup properly by parsing /etc/env.d/05gcc, instead of calling gcc-config .... -------------------------------------------------------- nosferatu root # time gcc gcc: no input files real 0m0.002s user 0m0.001s sys 0m0.001s nosferatu root # su nosferatu root # echo $PATH /sbin:/bin:/usr/sbin:/usr/bin nosferatu root # time gcc gcc: no input files real 0m0.007s user 0m0.002s sys 0m0.000s nosferatu root # --------------------------------------------------- Only about .005 seconds slower, which is about .03 less than it was =)
