Date: Mon, 12 Jan 2009 17:38:48 -0500 From: "John Dlugosz" <JDlugosz@TradeStation.com> Message-ID: <450196A1AAAE4B42A00A8B27A59278E70925C92F@EXCHANGE.trad.tradestation.com> | When you have a server farm of over 200 high-end multicore machines, | eeking a little more performance out is worth some programmer time, as | compared with the price of buying more servers. Even 1% is basically 2 | more machines on the rack, with its inherent cost of ownership. What kind of applications are you running that call mktime() enough that even if you reduced mktime()'s CPU cost to 0 you could possibly save 1% of the total system CPU usage? Have you measured this saving, or are you just speculation, as in "this is obviously faster so it must be worthwhile" ? If you were concerned more about low end embedded systems I'd tend to be a little more believing, but for high end multi-core machines if you can even measure the cost of mktime (unless you have very unusual applications) I'd be astounded. It certainly is not where I'd be spending my programmer effort! | Basically, I found me a niche where performance still matters <grin>. | www.tradestation.com. Performance matters just about everywhere, and if you can convince us (which does not necessarily mean me - in fact almost certainly doesn't) that there's actually a measurable performance win from the change, then it might get considered, but that has to be in an overall system context, not in a bogus "run mktime() a million times and count the cost" test. | Actually, I think that the more complex line of code isn't _that_ | complex, and saves a lot. I suspect it saves some of the cost of mktime() which for most people is saving some of nothing... | The real issue is testing. "Check everything" is less likely to have | a mistake. I'm actually making a comprehensive test which checks | every 15-30 minutes from 1930 through 2010, for every TZ file. Why stop at 2010? That's a little close. Also remember, this is mktime() - it has to convert all kinds of (bogus) struct tm's into a time_t - fully testing it is non-trivial. | Since I'm dealing with local times of various places in the application, | a major difference is to make timezone objects that can be instantiated, | rather than a single global setting. That certainly seems worthwhile. | BTW, what is the official way to refer to or cite this code and the | associated database? I see several names and abbreviations in use. Very good question, and again, I will defer to someone who might have a suggestion ("The ado timezone package" is probably what I'd use). kre