utc-time->seconds is abysmally slow on OS X

[Jim Ursetto]

This could be an os problem but I thought I would document it for later use.

Here is my test:

$ time csi -R posix -R srfi-1 -e '
(time (for-each (lambda (x) 
         (utc-time->seconds (vector 0 0 4 1 0 70 4 0 #f 0)))
     (iota 10000)))'

Here is my Linux box results (3GHz athlon X4 940):

0.02s CPU time, 200815 mutations, 5/57 GCs
real    0m0.041s

Here is my Mac OS X 10.5 results (c2d intel processor, 2.16GHz):

17.789s CPU time, 0.006s GC time (major), 200815 mutations, 5/5 GCs (major/minor)
real    0m54.934s

Overhead for vector creation in the test is about 0.05s and does not materially affect total time.

Note that local-time->seconds instead doesn't have this problem though (again on OS X):

0.091s CPU time, 0.003s GC time (major), 111 mutations, 1/9 GCs (major/minor)
real    0m0.123s

Weird!

[Jim Ursetto]

Use portable timegm on OS X

[Jim Ursetto]

In the patch above, I enabled the portable timegm() included in Chicken, normally used only for SVR4 which lacks this extension, and the results were 25 times faster on OS X:

0.863s CPU time, 0.011s GC time (major), 200783 mutations, 5/14 GCs (major/minor)
real    0m2.310s

A far cry from Linux and still 10x slower than local-time->seconds on OS X, but it beats the heck out of the terrible native code.

Whether this issue still exists on 10.6 is another question, I don't have it to test on (please pipe up if anybody does). I don't really want to activate this fix if a native fast timegm() is available in Snow Leopard, but it looks pretty important to include it on OS X 10.5.

If someone wants to test the speed on FreeBSD or NetBSD with and without the patch, that might be good too.

[Jim Ursetto]

I found someone mentioning that timegm() could be emulated on OS X via setenv() and mktime() but that it was "ass slow". This is also the suggestion given in the manpage on OS X: ​http://www.manpagez.com/man/3/timegm/osx-10.4.php. I thought perhaps that 10.5 had itself used this suggestion and that was the problem.

So I tried it and it is not "ass slow"--oddly it is slightly faster than the existing portable version:

1.003s CPU time, 0.01s GC time (major), 200783 mutations, 5/14 GCs (major/minor)
real    0m1.811s

I don't suggest using this version; I am simply expressing my bafflement as to why the native code is even "ass slower".

[felix winkelmann]

Applied in experimental branch.

[felix winkelmann]

Milestone 4.6.0 deleted