GTSystem Tech Blog

In my previous post (six months ago) I claim about the bad performance of Python 3.0. The first py3k version contained a new I/O library written totally in python that was the main cause of such problems.

Now Python 3.1 present a totally new I/O Library rewritten in c for maximum performance. As promised, I re-execute all my previus tests with the latest python version (3.1.1).

The next graph show the results, look at my previous post for details on the tests.

Different python version compared for performance

Text Read/Write

First you can see that the incredible bad text read issue is now solved. Python 3.1 is now much much faster, but it remain 2.42x slower than python 2.5. This is probably due to the text decoding phase. Text writing is now comparable to python 2.5.

Binary Read/Write

The rewritten I/O module is now able to read binary data faster than before. The same is not true for the writing performance that remain slow as Python 3.0.

Print

Another problem that I noticed in python 3.0 was the very bad performance on the new print function compared to the old print statement. In this test, Python 3.1 is now “only” 5 times slower than Python 2.5.

In general a good work was done to optimize py3k. I think that for general applications, py3k is now perfectly usable.

Many thanks to the python development team!

Python 3.0 (aka Python 3000) was released about a week ago.

In the what’s new the python team claim:

The net result of the 3.0 generalizations is that Python 3.0 runs the pystone benchmark around 10% slower than Python 2.5. Most likely the biggest cause is the removal of special-casing for small integers. There’s room for improvement, but it will happen after 3.0 is released!

In this week however, many people notice big performance differences in the new version versus the old 2.5/2.6 series related to I/O.

Since the read and write performance are very important for my work (data analysis), I did some tests in my laptop (MacBook Pro 2.4Ghz).

I installed from source code Python 2.5.2 and Python 3.0. Similar script has been compared by running them 5 times and taking average times.

Binary Read Test

Loading of a big file (156Mb) into memory in one step.

#!python2.5
import time
 
f = open("bigfile.txt","rb")
start = time.time()
f.read()
stop = time.time()
f.close()
print "%.3f sec" % (stop-start)

#!python3.0
import time
 
f = open("bigfile.txt","rb")
start = time.time()
f.read()
stop = time.time()
f.close()
print("%.3f sec" % (stop-start))

Read the rest of this entry »

In the latest release of the iPhone SDK 2.2 (9m2621) there is an issue concerning the localization procedure.

When the input string file is utf-8 and “Strings file Output Encoding” is set to binary, the resulting file isn’t Localizable.string but Localizable.string.XXXX where XXXX is a pid number.

To correct this issue you can patch the ruby script copystrings located in /Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/copystrings.

Simply change line 134 from:

system('plutil -convert binary1 -s -o "' + OPTIONS[:OutputDir] + '/' + 
File.basename(path) + '" -- "' + path + '"')

to

system('plutil -convert binary1 -s -o "' + OPTIONS[:OutputDir] + '/' + 
File.basename(path.gsub(".#{Process.pid}","")) + '" -- "' + path + '"')