Sunday, September 25, 2011

Speeding up Bash Profile Load Time

I started noticing a considerable delay whenever opening a new terminal or connecting to another server. After profiling my Bash profile with a few time commands, I discovered that the slowest part was the loading of the completion file:
$ time  ~/.bash/.bash_completion

real    0m0.457s
user    0m0.183s
sys     0m0.276s
The Bash completion script I use is from http://bash-completion.alioth.debian.org. I found that there is an existing bug for this issue #467231: bash_completion is big and loads slowly; load-by-need proposed and someone has submitted a script to speed up Bash completion load time called dyncomp.sh.

This is a one-time script, which only needs to be run when you install your Bash completions or modify them. It loads your completions and moves the completion functions out of the script and into a separate directory. They are only loaded when needed. This speeds up the load time considerably and new terminal windows open up instantly!

$ time  ~/.bash/.bash_dyncompletion

real    0m0.020s
user    0m0.018s
sys     0m0.002s
You can visit my GitHub dotfiles repository for the latest version of my Bash profile.

Saturday, September 17, 2011

Faster SSH with Multiplexing

OpenSSH allows you to speed up multiple SSH connections to the same server using "multiplexing". The first connection acts as the "master" and any other connections reuse the master instance's network connection rather than initiating new ones.

In order to set this up add the following to your ~/.ssh/config file:

Host *
ControlMaster auto
ControlPath /tmp/%r@%h:%p
ControlMaster auto will use a master if one exists, or start a master otherwise. ControlPath is the path to the control socket used for connection sharing. %r, %h and %p are replaced with your username, host to which you are connecting and the port respectively.

In addition, you may want to add Ciphers arcfour in order to use the arcfour cipher which is faster than the default (aes128-cbc). The transfer rate of arcfour is about 90 MB/s, aes128-cbc is about 75 MB/s and the slowest is 3des-cbc, at 19 MB/s.

Sunday, August 28, 2011

Profiling Perl Code

I've started using NYTProf to profile and optimise my perl code. It produces a very useful report showing how much time is spent in each subroutine and statement.

Usage:

perl -d:NYTProf script.pl
or
perl -d:NYTProf -I/path/to/Devel-NYTProf/4.06/lib/perl5 script.pl
The output of the profiler is written to ./nytprof.out.

Use the following command to create HTML reports from the profiler's results:

/path/Devel-NYTProf/4.06/bin/nytprofhtml --file nytprof.out -out ./htmlReports --delete

Wednesday, August 24, 2011

Play My Code: Chain Reaction

I've just published a new game called Chain Reaction on Play My Code.

Play My Code is a place where you can create your own online games easily using the site's Quby language. The games are compiled into native JavaScript, compatible with all modern HTML5-compliant browsers. Once you've written a game, you can embed it on your website or blog, like I have done below. It's like YouTube, but for games!

Here's Chain Reaction! The aim of the game, is to start a chain reaction (by clicking on the screen) and explode as many atoms as possible. See how many levels you can complete!

Click here to see all my games.

Sunday, August 21, 2011

Java 7: ThreadLocalRandom for Concurrent Random Numbers

The ThreadLocalRandom class in JDK 7, allows you to generate random numbers from multiple threads. It is more efficient than using shared Random objects and will result in better performance as there is less overhead and contention.

In addition, this class also provides "bounded" generation methods.

For example, the statement below generates a random number between 1 (inclusive) and 100 (exclusive).

int random = ThreadLocalRandom.current().nextInt(1,100);
Wait, there's a BUG!
While trying out this class, I noticed that the SAME random numbers were being produced across all my threads. I then discovered this bug which reported the same issue I was having. It appears that the seed is never initialised so the same random numbers are produced every time. I wouldn't recommend using this class until the bug is fixed. The following code illustrates the issue:
//3 threads
for(int i = 0; i < 3; i++) {
    final Thread thread = new Thread() {
        @Override
        public void run() {
            System.out.print(Thread.currentThread().getName() + ":");

            //each thread prints 3 random numbers
            for(int j = 0; j < 3; j++) {
                final int random = ThreadLocalRandom.current().nextInt(1, 50);
                System.out.print(random + ",");
            }
            System.out.println();
        }
    };
    thread.start();
    thread.join();
}
prints:
Thread-0:1,5,24,
Thread-1:1,5,24,
Thread-2:1,5,24,