Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#286 closed enhancement (fixed)

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

Reported by: Jim Ursetto Owned by: felix winkelmann
Priority: major Milestone:
Component: core libraries Version: 4.5.x
Keywords: utc-time->seconds slow molasses Cc:
Estimated difficulty:

Description

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!

Attachments (1)

timegm-osx.diff (1.0 KB) - added by Jim Ursetto 10 years ago.
Use portable timegm on OS X

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by Jim Ursetto

Attachment: timegm-osx.diff added

Use portable timegm on OS X

comment:1 Changed 10 years ago by Jim Ursetto

Priority: not urgent at allmajor

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.

comment:2 Changed 10 years ago by 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".

comment:3 Changed 10 years ago by felix winkelmann

Milestone: 4.6.0
Owner: set to felix winkelmann
Status: newaccepted

comment:4 Changed 10 years ago by felix winkelmann

Resolution: fixed
Status: acceptedclosed

Applied in experimental branch.

comment:5 Changed 9 years ago by felix winkelmann

Milestone: 4.6.0

Milestone 4.6.0 deleted

Note: See TracTickets for help on using tickets.