Summary
utc-time->seconds is abysmally slow on OS X
Metadata
- Id: b02fac3f112ba0e8282fbdc9736daa32a0df89b9
- Trac id: 286
- Type: enhancement
- Reporter: zbigniew
- Owner: felix
- Cc:
- Status: closed
- Component: core libraries
- Estimated difficulty:
- Resolution: fixed
- Priority: major
- Milestone:
- Version: 4.5.x
- Changetime: 2011-04-04 08:31:00 UTC
- Created: 2010-07-19 03:48:34 UTC
- Keywords: utc-time->seconds slow molasses
Attachments
- b02fac3f112ba0e8282fbdc9736daa32a0df89b9/attachments/timegm-osx.diff
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!
Changes and comments
[2010-07-19 06:35:37 UTC] zbigniew attached timegm-osx.diff (description=Use portable timegm on OS X)
[2010-07-19 06:46:56 UTC] zbigniew changed priority from not urgent at all to major
[2010-07-19 06:46:56 UTC] zbigniew wrote:
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.
[2010-07-19 07:02:15 UTC] zbigniew wrote:
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".
[2010-07-20 01:54:18 UTC] felix changed status from new to accepted
[2010-07-20 01:54:18 UTC] felix set owner to felix
[2010-07-20 01:54:18 UTC] felix set milestone to 4.6.0
[2010-07-26 10:04:03 UTC] felix wrote:
Applied in experimental branch.
[2010-07-26 10:04:03 UTC] felix changed status from accepted to closed
[2010-07-26 10:04:03 UTC] felix set resolution to fixed
[2011-04-04 08:31:00 UTC] felix removed milestone 4.6.0
[2011-04-04 08:31:00 UTC] felix wrote:
Milestone 4.6.0 deleted