Javia blog

Yesterday I ran the Warsaw Half-Marathon (21km) with time 2:00:58 (two hours and one minute). It was a very nice event, the weather was great (in fact I’ve got a bit sun-burnt during the run) and the running was not painful, quite the opposite. I improved my time from last year’s half-marathon with about 9 minutes.

What was particular this time was that I trained… almost not at all. All my training this year was one 10km run and one 9km run (the reason being that the weather was rather cold this spring, while I enjoy running above 10 Celsius; not to exclude pure laziness though).

Given my lack of training, I was afraid I won’t be able to even finish it — it’d be enough to run a bit too fast in the beginning, and I’d be dead at 15km. But everything went well, I could maintain an even rhythm all along, running with about 10km/h without any breaks. I didn’t notice the two hours going by, it seemed as if it were a mere 15minutes. And the weather was great.

I am a big fun of having the web’s huge and rich information available on mobile phones — it is really useful for the user to be able to browse the web with the mobile phone’s browser.

Some time ago I was wondering how this ‘mobile browsing’ experience can be improved, and at that point I was thinking that server-side page adaptation is the answer. In this approach, the web application generating the pages uses techniques such as User-Agent sniffing to detect that the client is a mobile phone, and returns a page specially-tailored for a mobile browser.

But now I realize that this approach is fundamentally flawed. It puts the burden on the web application developer to generate two parallel sets of outputs (one for desktop, one for mobile), and the hard part is keeping these two in sync. The problem is that the mobile version will get behind the desktop version, and the mobile user may be put in the paradoxical situation of wanting to browse the desktop version rather than the mobile version.

And the technology advances: my old mobile phone had a 128×128 screen, but now 240×320 is the norm for feature-phones (a feature-phone is the phone that is not as smart as a smart-phone). And the IPhone has a large QVGA screen (320×480). Such devices come closer and closer to displaying normal web pages, so the content-adaptation becomes less critical.

The solution that I see now is different: forget content-adaptation — instead design a single set of content, but take into consideration that a (growing) percentage of the users will be browsing from a mobile phone. So: keep the pages clean and streamlined, favour text instead of large graphics (text scales better), and keep the page size small.

Because the data connection on a mobile phone is slow, and often costs by amount of data transferred (not flat fee as on the desktop), it is important to keep the (total) page size small. This will greatly improve the browsing experience on the mobile phone.

In history there was a moment when most users were connected to the internet through a modem, with a maximum speed of about 5 KBytes/s. At that point, there was a lot of advice on the web on the lines of: keep the size of your web page under 10 KBytes — it would take so and so many seconds to download a web page of that size over the modem, etc.

I think it would be a good mind-set for present day web developers if they imagined that 20% of their users… are connected to the internet through modems again. So, forget the 1MByte (including images, ajax libraries, etc) web page, cause it takes 200 seconds to download it over the modem.

It’s true though, this new modem is getting faster…

Disclaimer: This blog expresses solely my own personal opinion — it is not endorsed by and does not represent the opinion of my employer.

I’m so happy I’m blogging again!

So, everybody knows already that I am the author of the Arity Arithmetic Engine, a nice little open-source library for evaluating arithmetic expressions. In this library I put quite some attention on the elegant and minimal code, and on performance. The functionality is mainly split in two parts: compiling an expression (takes a string and returns a Function object), and evaluating the Function.

For example, compiling the string “g(x)=x^2″ produces a Function instance. Calling eval(5) on this function returns 25. These two operations (compilation and evaluation) are separated because you typically compile an expression once, but evaluate it many times (for example when plotting the graph of a function).

On a desktop computer, Arity can do about 50,000 compilations/second, and about 1,000,000 evaluations/second. So the compilation is about 20 times slower than the evaluation.

Why is the compilation so slow? well, you may be surprised, but the bottleneck during compilation is the parsing of a double value from a string (using the java.lang.Double.parseDouble(String)).
And Double.parseDouble() is not only slow, it also does quite some memory allocations (which again result in slowness when the GC is invoked to collect that memory).

One key advantage of the Arity library is that it compiles not only on JavaSE (desktop Java), but also on JavaME/MIDP (mobile Java). So last weekend I decided to measure its performance on my mobile phone (a modest Nokia 6300). I wrote a tiny midlet for the benchmark, and the result is:

On the mobile phone, Arity does about 500 compilations/second, and about 10,000 evaluations/second. So the 20 times factor between compilation and evaluation speed is the same as on desktop.

And the key information, the mobile phone is about 100 times slower than the desktop computer (from Arity’s point of view).

Still, 10,000 evaluations/second on the mobile phone is not bad, I am quite happy with this performance.

PS: go check out Arity: http://arity.googlecode.com/