Mail Archives: djgpp-workers/2002/10/15/08:14:07
15-Oct-2002 01:28 you wrote:
>> perhaps a realistic estimates is around 3-10 times for others.
>> Preparing procedure set_hash_env() will effectively slowdown putenv() a bit,
>> but we putenv less frequently than getenv, right?
> If we cache getenv() properly in the tzset(), we'll only call it once.
Agree. That was my original point, but IZ resist.
> So there's the chance that you call putenv() more frequently (in
> initialization) than getenv() at runtime.
Sorry, my wording was incorrect:
the optimization procedure is called inside getenv(),
but only if there was an environ change since previous getenv() call.
(according to profile, load_environment_file mixes putenv and getenv calls.)
-----------------------------------------------
<spontaneous>
[187] 0.0 0.00 0.00 __crt0_load_environment_file [187]
0.00 0.00 8/10 __putenv [188]
0.00 0.00 13/71 getenv [194]
0.00 0.00 1/171757 malloc [33]
0.00 0.00 1/137564 free [41]
-----------------------------------------------
> With the very sparse distribution of letters, I think it would be much
> more space efficient to mask the lower 4 or 5 bits for the buckets
> (16 or 32 should be fine, 256 is overkill). This also would speed up
> the initial setup.
Indeed...
> Here's my proposed patch for ctime.c:
yes, I saw this also.
> *** ctime.bak Sun Jun 9 13:20:22 2002
> --- ctime.c Tue Oct 15 01:24:06 2002
> *************** tzset(void)
> *** 920,926 ****
> /* If environ didn't changed since last time, don't waste time
> looking at $TZ. */
> ! if (lcl_is_set > 0 && __environ_changed == last_env_changed)
> return;
> /* If environ did change, but $TZ wasn't changed since last time we
> --- 920,926 ----
> /* If environ didn't changed since last time, don't waste time
> looking at $TZ. */
> ! if (lcl_is_set != 0 && __environ_changed == last_env_changed)
> return;
> /* If environ did change, but $TZ wasn't changed since last time we
- Raw text -