Computers today have tons of processing power. Who really cares about algorithm design when the computer can perform millions of calculations per second? This was a common thought of mine until recently.

When I learned big O notation and performance estimation in university I often thought to myself that I would never need to remember it, and it was not really useful for programming today. I was way off. Big O is something I have recently started using again and encourage every programmer to use as a way of estimating algorithm performance.

When we started making Wezzle we initially began designing without real thought of efficiency. Our initial implementation was all about design. However, we were very inexperienced when it came to actually designing good quality code. We quickly ran into some severe performance issues, and the Wezzle design still has some major flaws that really aren’t worth fixing at this point. One thing I can say with certainty is that my understanding of good design has improved by a drastic amount from this experience.

Our initial game design included the use of Scalable Vector Graphics (SVG). We chose to use SVG because we liked the way they looked and the fact that window resizing was a non-issue. However, we failed to take into account how performance critical games truly are, and how incredibly slow SVG graphics are.

Our initial game was extremely choppy and virtually unplayable on old machines. We spent a lot of time trying to figure out why that was and how to boost performance. Eventually we decided to bitmap our graphics and noticed a SUBSTANTIAL increase in playability and performance.

I was pretty shocked by this entire scenario. First, I had always assumed that performance today was a non-issue, and second, I never thought that the type of graphics we used would make such a huge difference in terms of performance.

SVG wasn’t even close to all of our performance issues with early versions of Wezzle. We had a bunch of calls that were needlessly being made every game tick (we still find this problem with some of our code) as well as various other design flaws that affected overall performance. We had an inefficient algorithm to refactor the board and just in general a lot of areas that could be streamlined. We also had a bunch of performance issues with label generation (which we fixed with a cacheing scheme) and some troubles with phantom references (yuck!). We made extensive use of the built in profiler in netbeans during our first refactoring phase.

Since then Wezzle has gone through countless refactorings and countless optimizations. Another huge increase in performance came when we switched from Java2D to OpenGL (lwjgl). Perhaps in a later post I will talk about some of the various optimizations we have employed in Wezzle, but that is beyond the scope of this article.

Even with all the performance issues in Wezzle, I thought to myself that games are kind of a unique situation that is very performance critical and lots of calculations are happening, maybe performance is only relevant to gaming.

Again I was wrong. As anyone who does any web development can attest to, large database operations can be TERRIBLY inefficient. I am currently under contract developing some code that loads a large number of records into a grid structure. I am limited by the fact that this grid is only usable to us by passing it XML on the client side, as well as various restrictions about look and feel that were dictated by my client. Perhaps in a future post I talk about the multitude problems with the grid I am using, and there are many, but that would take way too much space to type in this post.

Anyway, my first implementation which contained some optimizations took around 15 minutes to update 500 records from the grid. The records were huge and data validation was being done on every individual cell and since the grid had to be submit as a whole (as an XML string) I was parsing and updating the entire grid.

This was not acceptable and also mildly surprising. Going through my code I have optimized even more. I implemented a dirty cell scheme, marking cells which have been edited as dirty so that on the submit I can only validate cells which have been marked as dirty. This assumes that all data already in the database is valid (not always the case!). I validate pasted in values at paste-time and that’s it (once they pass validation, they are considered good from the client side). Finally, I mark records which have been modified as dirty and even though I still have to submit the entire grid, I now only parse the records that have been marked and skip the rest. This has vastly improved update performance on the average case. It has improved updates in the worst case as well, but not by quite so much, a full submit still takes some time.

I’m going to end this by saying that while yes, performance is an issue, it is also sometimes a non-issue. First and foremost you should code something for clarity. A clear design that is slightly less efficient is always better than a streamlined but cryptic design. It is a mistake to optimize something that doesn’t actually need optimization and a big time waster. A popular saying is “design for clarity first and foremost and use a profiler to determine which areas need to be optimized.” This idiom does make sense and makes a valid point, but I would instead say to design for clarity and performance in conjunction as performance can often be a surprising bottleneck.