Performance

Unchain your computers!

So far, the question of whether or not machines are free has rarely been discussed because we usually have to deal with less philosophical problems.

But, in a World facing raising fixed costs and lower revenues, this issue is becoming less and less a matter for the literate.

The httpdate.c benchmark below (try it live here on Linux) might help the ones willing to make progress in this matter:

How much time should it take to format an RFC-1123 HTTP date string like "Tue, 06 Jan 2009 06:12:20 GMT"?

We answer with an Intel XEON 3.06GHz on Windows XP Pro SP3: (calls are placed in the CPU cache before a 10-round timing).

G-WAN's time2rfc() is a thread-safe equivalent of the code below:

1
2
3
4
5
6
7

char *time2rfc(time_t t, char *date)
{
   time_t tt = t ? t : time(0);
   tm *ptm = gmtime(&tt);
   strftime(date, 31, "%a, %d %b %Y %H:%M:%S GMT", ptm);
   return date;
}

Let's see how G-WAN C scripts are doing when compared to the WinInet InternetTimeFromSystemTime() Windows API call:

function    max  average  min  (cpu clock cycles)
---------- ----- ------- -----
WinInet    9,862   9,688 9,218 (on average, Windows is 16x slower than G-WAN C scripts)
time2rfc()   634     604   590

When zipping a folder while testing, results were even better:
(because concurrent tasks compete for CPU cycles and CPU caches)

 function    max   average  min  (cpu clock cycles)
---------- ------- ------- -----
WinInet    431,086  52,921 9,874 (on average, Windows is 85x slower than G-WAN C scripts)
time2rfc()     694     662   558

In the worse case, Windows is up to 621x slower than a G-WAN C script.

The fact that the most common OS works so much slower than a script engine should – at least – raise some questions.

This simple case illustrates how G-WAN can leverage your servers – and how much your developments will benefit from using it.