Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Daylight Savings Time: how to fix ctime.c
Message-ID: <15367@sun.uucp>
Date: Fri, 20-Mar-87 05:24:28 EST
Article-I.D.: sun.15367
Posted: Fri Mar 20 05:24:28 1987
Date-Received: Sun, 22-Mar-87 23:20:08 EST
References: <5040@brl-adm.ARPA>
Sender: news@sun.uucp
Lines: 83
Summary: *What* sacrifice?

> Unfortunately, such an implementation sacrifices execution speed for
> the sake of rule flexibility.

Oh, really?

	gorodish$ time /bin/date	# 4.2BSD version of "ctime"
	Fri Mar 20 02:11:32 PST 1987

	real	0m0.10s
	user	0m0.01s
	sys	0m0.03s
	gorodish$ time /bin/date
	Fri Mar 20 02:11:35 PST 1987

	real	0m0.10s
	user	0m0.00s
	sys	0m0.06s
	gorodish$ time /bin/date
	Fri Mar 20 02:11:38 PST 1987

	real	0m0.10s
	user	0m0.00s
	sys	0m0.08s
	gorodish$ time /usr/5bin/date	# S5 version of "ctime"
	Fri Mar 20 02:11:43 PST 1987

	real	0m0.41s
	user	0m0.01s
	sys	0m0.11s
	gorodish$ time /usr/5bin/date
	Fri Mar 20 02:11:46 PST 1987

	real	0m0.10s
	user	0m0.00s
	sys	0m0.10s
	gorodish$ time /usr/5bin/date
	Fri Mar 20 02:11:48 PST 1987

	real	0m0.10s
	user	0m0.00s
	sys	0m0.08s
	gorodish$ time ./date		# Olson version of "ctime"
	Fri Mar 20 02:11:51 PST 1987

	real	0m0.20s
	user	0m0.01s
	sys	0m0.08s
	gorodish$ time ./date
	Fri Mar 20 02:11:53 PST 1987

	real	0m0.15s
	user	0m0.00s
	sys	0m0.08s
	gorodish$ time ./date
	Fri Mar 20 02:11:54 PST 1987

	real	0m0.11s
	user	0m0.00s
	sys	0m0.06s
	gorodish$ 

The CPU time differences seem insignificant.  I suspect if you did a
more rigorous test, the differences would be statistically
insigificant.  Other than the startup transient (most likely due to
pulling the file into the buffer cache), the real time differences
were minor as well.  (I'd say that large startup transient for
"/usr/5bin" reflected the fact that the program is being fetched via
NFS, except that both the test version of "date" *and* its data files
are being fetched over NFS here.)

Other tests I've done (a test doing one call to "ctime" on the current time,
and a test doing lots of them) show much the same thing.

Less speculation on what will or won't be expensive, and more data,
please!  Just because it "makes sense" that X will be more expensive
than Y doesn't mean it *will* be.

There are places (Australia, for one) where rule changes *do* seem to
be frequent.  Given the small extra cost of the file-based DST
scheme, were I in Australia I would be more than willing to use it to
avoid having to recompile tons of software (or recompile *and* send
out updates, in the case of a vendor, or wait for said vendor to send
out the updates, in the case of a binary-only customer).