It also has value in other areas. For example, it is possible to make any binary -- even an entire virtual machine -- send all network traffic through SOCKS by wrapping it in a socksify library. You can't do that on Windows or (to my knowledge) OSX.
Part of the strength of Linux is how unbelievably hackable it is. I don't see the point in sacrificing this flexibility for a tiny microoptimization. And it's very tiny... that code has no branches and is just a couple of MOVs, so it's just going to get pipelined. It would only be worth it if it involved a bunch of extra conditional branching. Removing a few MOVs per function call is going to do nothing. It might literally do nothing, given that it might be buried beneath the waves of branch prediction failure overhead, cache misalignment overhead, etc.
Linux performance is not a problem at the low level. Linux performs very, very well. Its disk and memory allocation performance is noticeably superior to any other OS on the same hardware, in my experience.
The problem with Linux is usability and cruft.
I'm at loss here -- how is micro-optimization not necessary anymore? Both the CPU, the FSB and the DRAM hit {G,M}Hz barrier. The /only/† advance in performace we are getting those days are `horizontal' scaling (more cores) and micro-optimizations like better branch prediction, prefetch etc. And yes, better compilers. Note how every other generation of various busses flip-flop between serial (for increased signaling speed) and parallel (for increased bandwith) transmission. In short: the silicone free lunch is over, probably until we get abundant memristors or something.
What we need is to help the CPU execute our code, which has a lot to do with reducing cache misses. Get rid of ELF shlib indirections like GPT, lessen amount of paging metadata to lessen amount of TLB misses, simplify run-time dynamic linking etc., etc.. I guess some will shift to static linking some libraries, to get rid of indirection and unused code. IIRC MPlayer already provides some ./configure option(s?) for statically linking some libs exactly to get better performance.
Besides, when you think at the scale of Google or FB, one microsecond optimization multiplied by the sheer number of the CPUs they burn adds up to significant money.
> another incompatible ABI change would kill linux dead.
a.out to ELF32 was handled just fine, and ELF32 to ELF64 is going pretty well. What is your point?
†aside of HDD -> SSD transition, which is of mechanical -> solid state nature.
libc 5 -> 6 was awful, as was gcc 3.4's C++ ABI change. I think the typical ubuntu user would leave and never come back if they went through either of those.
I suspect that the compiler generates the indirections itself to handle linkers that can't; making the linker easily replaceable involves a bit of overhead now but gains us in the long run (e.g. it allows new linkers like gold to be developed more quickly).
If you want to microoptimize how the linker loads function addresses on x64 then be my guest. Just don't expect the devs to treat it as high priority
As the article says, visibility modifiers exist and can be used by those who care about them. I think that will have to be enough, in the interests of usability.