How fast is Python dictionary?

Based on textbook theory: O(1).

I was about to do a profile test on it, but found this discussion on the mailing list. One poster claim 0.2 seconds per 1 million keys.

Perfect.

How Java supposed to look like on OS X

Quaqua is open source UI java library for OS X. Subjectively, IMO, it looks better than Swing and feels native on OS X.

Reference:

Quaqua project page

The button Factory

This is so useful for programmer who cannot do AWESOME design… Like me.

Even Matz love Python

Matz love Python

Python: cPickle vs ConfigParser vs Shelve Performance

I need to store large number of key-values to map my Python objects. These key-values DO NOT have to be replicated across multiple servers and  the project DOES NOT require external storage systems such as RDBMS or Berkeley DB or others. The least external dependencies the better.

That leads me to cPickle vs ConfigParser vs Shelve. cPickle is obvious contender, it is fast and easy to use.

ConfigParser is an interface for writing config file, but its format is very key-value ish, so it counts.

Shelve is obvious too, because of its interface.

So I ran profiler test using hot shot and here’s the result:


Profile: Saving 100000 key-value to pickle file
700001 function calls in 2.330 CPU seconds

Profile: Extracting 100000 key-value from pickle file
4 function calls in 0.258 CPU seconds


Profile: Saving 100000 key-value in ConfigParser file
900004 function calls in 2.502 CPU seconds

Profile: Extracting 100000 key-value from ConfigParser file
300007 function calls in 1.936 CPU seconds


Profile: Saving 100000 key-value to shelve file
1300047 function calls (1300045 primitive calls) in 10.091 CPU seconds

Profile: Extracting 100000 key-value from shelve file
500027 function calls in 6.527 CPU seconds

From the results:

• Shelve is disappointingly slow. It execute 1,300,047 calls???
• cPickle is not bad at all. As expected, it performs really quick.
• ConfigParser is the biggest surprise here, I was expecting it to be much slower.

Side Notes:

• I use threading.Lock before setting the key-value to prevent resource contention (which is real life case).
• Any improvements is greatly appreciated. Especially different data storage that I’m not aware of.
• Code can be found here.

Wiki is 14 years old now

Ward Cunningham celebrates wikis’ birthday with his colleagues at AboutUs.

How to get Merchant Account

The author puts together his experience dealing with various hoops and dance in order to get merchant account.

I think the post is a good experience for other to learn from.

Tokyo Cabinet/Tyrant for Python Programmers

1. Tokyo Tyrant Tutorial

2. Tokyo Tyrant Documentation

3. Starting Tyrant Server as Daemon: (casket.tch is the database)

ttserver -dmn -pid /tmp/ttserver.pid /tmp/casket.tch

4. Best documentation on how to install Tokyo Cabinet & Tyrant: http://openwferu.rubyforge.org/tokyo.html

I personally go the git route.

5. To get the ‘distributed‘ feature, use Memcache Client to connect to Tokyo Tyrant server. The default port is 1978.

6. In my opinion, Tokyo Tyrant works best as Cache/Session/find_by_id solutions.

References:

• PyTyrant Benchmarking
• pytc
• pytyrant
• python-memcached

The real reason why C++ was invented

First of all, I’m not sure if this post is for real. If so, shocking. If not, it’s a very good humor.

In short, the real reason why Bjarne Stroustrup created the language is to keep software engineer salary relatively high, C++ developers nowadays indeed have very good salary.

He also mentioned that C++ doomed Mentor Graphic big time.

Read it for yourself.

C and C++ Interpreter

I never imagine anyone would bother inventing it, but some folks at ROOT (associated with CERN) thought otherwise.

The project is called CINT. It is written in C++. It is open source under MIT license.

This is gonna be fun.

Reference:

CINT page