On Tue, Aug 10, 2010 at 12:02 PM, Sad Clouds <cryintotheblue...@googlemail.com> wrote: > On Tue, 10 Aug 2010 11:59:25 -0400 > James Carlson <carls...@workingcode.com> wrote: > >> I'm afraid I don't follow the example. How is it that getting data >> from the network (which involves at least a read() system call and >> data copying) isn't several orders of magnitude slower than getting >> the current time of day? How is it that clock_gettime() isn't >> completely buried in the noise? > > It depends on what your application is doing, and how fast/slow > clock_gettime() is. For example a quick test on Linux shows that on > average calling clock_gettime() is 1.6 times slower than calling read() > on /etc/passwd. If you can decrease system time by 1.6 times, that's a > big improvement. > > Another example, you cache file data in memory. Suppose this data is > dynamically generated by an fcgi script, or similar, hence you don't > want to cache it for more than 5 seconds. For every file you find in > cache, you need to get current time and calculate if the file has > expired and needs to be reloaded, or can be served from cache. If the > rate at which you scan your cache is high, calling clock_gettime() for > every file will add to your system time. In fact, calling clock_gettime > every second would be sufficient.
I think gethrtime() would work just fine for that, since you're concerned about intervals and not absolute time... _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
