A chess engine in JavaScript: performance issues

lib-gwt-svg-chess was originally developed as a demonstrator for lib-gwt-svg. I began by looking for a chess engine with the following requirements: java-based, maven project if possible, minimum dependencies on non GWT-compatible libs, clean design to allow refactoring if needed. There were several possible contenders (chessbox port of GNU-chess, chesspresso), but only Carballo matched all my criteria.

My first step was to refactor the code so as to extract all the non-GWT compatible parts to an external project (applet UI mostly, configuration, opening book reader). I added extra hooks to let me provide alternative implementations for the parts which could not work in a GWT context (opening book, configuration). The alternative refactored version has number  0.3.1, though it does not have any extra functionality compared to the original 0.3 version.

I wrote my UI and started my debugging in developer mode. Everything went fine and I thought I was almost done. Then I tried production mode and discovered the program did not even start.

It turns out that the problem was mostly a performance problem. For all the competition occurring between JavaScript engines, JavaScript performance is still considerably slower than Java. Carballo starts by initializing what it calls “attack tables” (basically, a 100 000 element array of longs which represent chessboard configurations). In Java, this takes 0.5 seconds. If JavaScript, which lacks native longs and uses an emulation library, this step took 120 seconds. So I tried to trade time for space and decided to precompute the table as a large JSON structure which gets parsed at the beginning of the program. Contrary to the interpreters, the browsers javascript parsers are quite fast and I was down to 3 seconds for this part. However now the end user has to download a 3mb file full of longs just to initializa the program. Activating mod_deflate enables gaining some of this space back.

Another not yet solved issue is the issue of liveness. When the computer is thinking, one would like the UI to remain responsive. There are no threads in JavaScript, but the new web workers API introduced in HTML5 could theoretically do the trick. Maybe that could work with extra hacking, but not out of the box, since GWT requires special initialization code which is not compatible with web workers (my biggest complaint about GWT at the moment)