Environment handling broken in /bin/sh with changes to {get,set,put}env()

[Sean C. Farley]

On Sat, 7 Jul 2007, Andrey Chernov wrote:

> On Sat, Jul 07, 2007 at 01:51:11PM -0500, Sean C. Farley wrote:
>> I agree that it would be faster for a subset of an existing environ.
>> On the other hand, in the case of emptying the environment, my method
>> would be faster since no deallocation, allocation nor setenv() calls
>> would be called assuming putenv() was not used.  I could try a few
>> tests to see what is faster in which case, but I do not think environ
>> changes happen often enough to make speed a factor.
>
> Well, lets go with that.

I ran the tests out of curiosity.  All code is here[1].  The dropping
was effectively freeing envVars and the environ that getenv.c creates
for the program.  All other counters were set to zero.

The first test (timing-clear.c) cleared the environment by swapping two
char ** arrays containing a single NULL pointer.  500000 iterations.

x drop/clear-timings.txt
+ keep/clear-timings.txt
     N           Min           Max        Median           Avg        Stddev
x  50      1.634899      1.672082      1.656838     1.6567984  0.0093033009
+  50      1.326203      1.348855     1.3296575     1.3323876  0.0062632107
Difference at 95.0% confidence
 	-0.324411 +/- 0.00314674
 	-19.5806% +/- 0.189929%
 	(Student's t, pooled s = 0.0079303)

The second test (timing-merge.c) swapped two duplicates of my
environment over 5000 iterations.

x drop/merge-timings.txt
+ keep/merge-timings.txt
     N           Min           Max        Median           Avg        Stddev
x  50      1.337052      1.406142     1.3663635     1.3634524   0.015210835
+  50      0.889559      0.913354     0.8943785    0.89644634  0.0056274351
Difference at 95.0% confidence
 	-0.467006 +/- 0.00455057
 	-34.2517% +/- 0.333753%
 	(Student's t, pooled s = 0.0114682)

Surprisingly, keeping the pointers saved time even if calling setenv().

Sean
   1. http://www.farley.org/freebsd/tmp/setenv/clearenv/
-- 
scf at FreeBSD.org