From: Charles Sandmann Newsgroups: comp.os.msdos.djgpp Subject: Re: profiling with DJGPP Date: Sat, 12 Oct 2002 15:28:01 CDT Organization: Rice University, Houston TX Lines: 22 Message-ID: <3da885d1.sandmann@clio.rice.edu> References: <2 DOT 7 DOT 9 DOT 191MP DOT H3U9EW AT pauzner DOT dnttm DOT ru> <2 DOT 7 DOT 9 DOT GKAP DOT H3VJYA AT pauzner DOT dnttm DOT ru> NNTP-Posting-Host: clio.rice.edu X-Trace: joe.rice.edu 1034455124 27279 128.42.105.3 (12 Oct 2002 20:38:44 GMT) X-Complaints-To: abuse AT rice DOT edu NNTP-Posting-Date: 12 Oct 2002 20:38:44 GMT X-NewsEditor: ED-1.5.9 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > >> 2) getenv heavily used by timer functions for timezone info > >> (TZ, TZDIR, etc. - seems things are stored in static > >> variables but probably not in all places?) > > Only once: the time functions cache the values of environment > > variables. If your program changes the environment a lot (by calling > > putenv or setenv, for example), then caching could be ineffective, > > since each time the environment changes, time functions must see if > > some of their variables changed as well, and take note. This is so > > that setting TZ to a different value is correctly handled. > The profile shows - each tzset force calling tzsetwall > (TZ variable is not set in my environment). Have you tried setting TZ to see if the profile changes/improves? A casual inspection of ctime.c (I'm not an expert) looks like to me that at least the first comparison of lcl_is_set should be !=0 instead of >0 to cache the case where TZ is not set. You could try modifying ctime.c in such a manner to see if it improves performance (and still works).