I have been in Sydney for the past week for UDU, which wraps up tomorrow. It has been great meeting up with everyone again, but has also been exhausting.
Some of the stuff on the horizon will be quite ground breaking. For instance, I don’t think anyone has attempted something like Grumpy Groundhog (which will hopefully be very useful to both the distro team, and upstream projects like Gnome).
Experimented with using the new ELF visibility attribute support in GCC 4 in Python, and came up with this patch. It restricts the list of exported symbols to just the ones marked with the PyAPI_FUNC and PyAPI_DATA markers, which omits all the private symbols that /usr/bin/python or libpythonX.Y.so export.
In addition, it uses “protected” visibility for all the exported symbols, which means that internal calls to the public Python API don’t have to go through the PLT (which they do if Python is compiled as a shared library).
In the shared libpython case, this speeds things up by about 5% (according to pystone and parrotbench), which isn’t too bad for a small patch. In the static libpython case, it seems to slow things down slightly — by < 1% in my tests so far.
Of course, the shared libpython case is still slower than the static version (which is why /usr/bin/python doesn’t use a shared libpython on Ubuntu), but it does make it less slow than it was before
Glynn: If Solaris feels like a second class citizen, it is probably because hardly any hackers have access to Solaris machines (the same seems to be true of architectures other than i386). A fair number of developers would probably be interested in fixing Solaris build failures if they knew that they existed.
I realise that Sun doesn’t want to provide external access to a build machine (at least, that’s what I was told last time I asked some Sun/Gnome hackers), but maybe running a tinderbox style system and publishing the build logs would help. As well as telling me if my package is broken, it’d give me a way to tell whether the fixes I check in actually solve the problem.