Simple Performance Improvement
Wednesday, June 26, 2003

By slowjoe
TopCoder Member

Introduction
At the Collegiate Challenge finals, there was a discussion about improving performance levels, and it made me think. Someone asked two questions: when should he expect his performance to peak, and how high should he expect to go. No answer was given, not surprisingly.

I'd like to share a few of my thoughts on improving performance in areas other than pure programming ability.

Talent
I've heard it said of soccer players that talent dominates until the age of twenty, and after that point, focus and hard work become more important.

I don't think this is true of coding. No one was born knowing Dijkstra or Floyd-Warshall. Everyone has to learn the standard algorithms. On the other hand, some people learned these things earlier than others. I know that many of the leading coders (for example, SnapDragon, dmwright, reid and dgarthur) represented their country at the high school level. I'd say there are two groups of coders: those who have slaved over algorithm textbooks, and those who ought to do so.

On the other hand, here are some simple things you can do which will significantly improve your performance, which will mean more points at the end of match.

People
I've scored zero a couple of times because my girlfriend has picked a fight halfway through the first problem. I'm probably not the only person to have such an experience. The important people in your life should come first: don't lose a girlfriend just because of TopCoder. Likewise, TopCoder is not worth losing a job or failing an exam over. The best advice in this column is in the next sentence.

Make sure there are no urgent problems you should be dealing with while the match is on.

Try to ensure that your friends and family respect your time and space during a match. If you're in high school, tell your Mom that you feel TopCoder is a career move. If your wife is concerned about the time, phone one of her friends and offer to pay for them to go out to dinner together...on TopCoder night. Even bringing home a bunch of flowers or box of chocolates on TopCoder night will reinforce positive associations. Trust me, it works.

Computer Setup
The TopCoder applet requires a significant amount of memory. It's worth testing what does and does not cause problems with your computer. My setup has 128Mb of RAM, and I like to run a web browser on the java API docs, as well as the applet and the PopsEdit java plugin. I have had swapping problems with this, so if you have less than this, it would be wise to consider upgrading your box.

Other people I've spoken to tell me they have an old modem and ISP account so they have backup in case of network outages. Overkill? Maybe, but imagine being a red or high yellow knocked out of the Invitational because of a network outage.

Software Setup
There is only one thing to say about using JVI or Standard editor:

DON'T

Your editor, its setup, and your knowledge of it are the clearest areas where coders rated blue and below can improve. Can you tell me what's good about your editor? If the answer is "no", you can score at least 50 points extra a match by putting some time in here.

(Reds and Yellows probably already know their tools. In the case of the top reds, their typing speeds are likely so high that the advantage from editor tuning is small.)

So what should you look at in a good setup? Well, there are standard things that any usable editor has:

Syntax coloring/error highlighting
Auto-indentation support

If your editor doesn't have these, then you should change! PopsEdit gives you these, and other possible solutions (used with FileEdit) are Visual Studio, Emacs, Vim or JEdit (the last 3 are free.)

Especially for match performance, you should think about the following features:

1. Local compiling and debugging.

Not always necessary, but sometimes the applet runs slow. On several occasions during matches (including cancellations due to poor compiler performance on the server), I haven't been aware of the problem until compile/submit. When performance problems strike, having compile and debugging features has added at least 100 points to my score.

2. Abbreviations.

My typing speed is 30-40 words per minute. The top reds are likely pushing 100 wpm and upwards. How do you close the gap? Well, if you hunt-and-peck, it may be worth doing typing drills. Another, more productive way to improve is to program your editor to do the typing for you.

I've aliased "fri" to:

for (i=0, i<^; i++) {
}

(the cursor appears at the caret). For 4 keystrokes, I get much more.

I've got a similar alias "stk":

StringTokenizer st = new String Tokenizer(^);
String tok;
while(st.hasMoreElements()) {
   tok = st.nextElement();
}

There is one strong argument against this sort of thing: you won't be able to use it if you get to an onsite final round (you only get a vanilla PC and 15-30 minutes to set it up, no notes allowed.) To a high-ranked red, this may be a significant factor.

In my opinion, if you've written the same code more than twice in match solutions, you should add it to a code/alias library. There is more that can be said about a code library. Ideally, it should be kept fresh. My library has been pruned as I've come to rely on Java's Collections API more, and my coding style has changed. Ideally, each alias should either be documented (I marked up my contestapplet.conf file in html at one point) or memorized.

But you should really think about a code library if you haven't got one. Trust me on this one.

3. Testing.

Pops and others have written plugins to extract test cases and create a framework to run them. With a single key press, you can then run all the example tests, and see the results. This is like a golfer being able to hit a driver 100 yards further.

It also avoids the potential embarrassment of failing one of the example tests. I've done that. It sucks!

I originally wrote this article before the arena changes that allow running of example test cases. At that time I included the line:

You absolutely have to be able to run the example tests via a single keystroke. There is no discussion.

Now, of course, matters have changed. Anyone who fails one of the example test cases has nowhere to hide. One-key test execution has changed into an issue of relative competitive advantage. Once again, ask yourself the question: "Where is my testing setup better than the setup of my rivals?"

This is by no means an exhaustive list of things to try. Many sports have seen enormous innovations, which changed the game. For example, wide-body tennis rackets with over-sized heads (expected to be used mainly by seniors) have completely changed tennis. Innovation is an arms race: you have to keep working to maintain parity, let alone an edge.

Would you like to write a feature?