"Software is getting slower more rapidly than hardware becomes faster."
(Wirth's Law - Niklaus Wirth, ETH Zurich)

Unchain your computers!

So far, the question of whether or not machines are free was rarely discussed because most users had 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 litterate.

The benchmark below (one of the servlet samples) might point one thing or two for anybody willing to find a solution:

How much time should it take to format a 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 this code:

char *time2rfc(size_t t, char *date)
{
  size_t tt;
  if(t) tt = t; else tt = 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 servlets are doing in comparison to the 
system WinInet InternetTimeFromSystemTime() Windows API call:

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

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

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

In the worse case, Windows is 621x slower than the C script.

The fact that a compiled operating system works so much slower than a script engine should - at least - raise some questions.

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