If you want to debug postinst scripts, you can easily do this on the machine where you (half) installed the package. Normally you can execute /var/lib/dpkg/info/foo.postinst like this:

sh -x /var/lib/dpkg/info/foo.postinst configure


However, if you use debconf, the output will be like this:
+ . /usr/share/debconf/confmodule
+ [ ! ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [ ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/foo.postinst


Which is not helpful either. However, you can add “set -x” in /var/lib/dpkg/info/foo.postinst and then just execute it, it will give you the full output.


sh /var/lib/dpkg/info/foo.postinst configure


Now the debugging process can begin!

When only one package is made, this is easy: just install the files in debian/tmp as you would when installing on the system. For multiple packages, each package has its own directory: debian/<package-name>. How does dh_builddeb figure out which directory to use?

Apparently, the default behaviour is to let the first package use the debian/tmp dir, and the other packages use the debian/<package-name> directory.

I would rather have them all using the debian/<package-name> directory, but I could not find an option to do this.

Update:
It seems that setting the compatibility level to 7 fixes this behaviour (echo “7″ > debian/compat), see man debhelper (section “Compatibility levels” for more info.

Looking at Activity Monitor, a lot of I/O was done, both reading (1-2 MB/s) and writing (0.5 MB/s). I expected reading, but writing? The change in calling the training program was the the filenames it should read. In the fast case, it was reading all filenames, to train on all data. in the slower case it was reading a somewhat smaller subset of these files, to train for K-fold cross-validation.

The thing is, the somewhat smaller subset was generated by picking random filenames, so it was unsorted. This caused the trainer to read files non-sequentially (while the order doesn’t really matter). Apparently, this caused a lot of load in writing the access times of the accessed filenames. Because the directory has 14380 filenames, a non-sequential update of the access times apparently is not very nice on disk I/O.

Sorting the smaller subset on filename caused the trainer to have a CPU usage of over 70% and an appropriate shorter run time as well!

This was on a local test-server, so there was almost no latency. Testing the same site when I was remote, the response times were around 600-800ms for each call (I don’t know the exact numbers now). Since each request has a certain startup-time, and since we are still using CGI instead of mod_python (for debugging purposes) it seems reasonable to assume that the startup-time is high, relative to executing time. That’s why I tried combining the three requests into one.

What I did is adding optional arguments to the getpermissions call. If these arguments are present, it also returns the corresponding list. Testing response times with this changed code resulted in the same response times. So far so good.

Testing the code with the combined call resulted in a 160-180ms response time. This is exactly the same for the getpermissions call without querying the lists! Apparently the CGI has a very high impact, and the list generating code very low impact.

All in all this resulted in a 260-300ms improvement, on my local testing network! This is noticeably faster. I’m glad :)

Yes, exceptions are slower, just a bit.

Test setup

The test-program first wastes some CPU time in a recursive function and using a loop. This is to simulate a real-time CPU-intensive task which has deeply nested functions. This process runs twice, first with high values of looping and recursing and another time with no looping and no recursing. Then the program prints the time spent and the ratio between throwing/nonthrowing functions on both runs.

Results

Typical output of the program:

ratio throwing/nonthrowing: 3.09256e+06ms / 3.07183e+06ms = 1.00675

ratio throwing/nonthrowing: 3ms / 3ms = 1

Normally, the program doesn’t throw, but does try to catch exceptions because we want to know the performance of the situation where nothing goes wrong. If something does go wrong (and an exception is thrown) the following output may be observed:

ratio throwing/nonthrowing: 3.16843e+06ms / 3.16829e+06ms = 1.00005

ratio throwing/nonthrowing: 42ms / 3ms = 14

Conclusions

Apparently, actually throwing an exception does cost some time, but when everything is ok the performance is a tiny bit slower: about 0.65%, calculated from the test run.

Notes

The program was compiled and tested on an Athlon 900Mhz, with the following command:

g++ -o exceptions exceptions.cc -O3

Apologies for the ugly code :)