Closed hnakamur closed 12 years ago
@kristate Thanks for your experiment. I add other methods and tried myself. https://gist.github.com/3735229
In this microbench, type_c is the fastest. However, the time for running once is about 0.66 / 2e6 = 0.33 microsecond. I suppose the count of worker is the same as number of cores in CPU like 4, 8 or 64. So I think differences among types are negligible.
Variable length arrays used in type_c needs C99. http://www.drdobbs.com/the-new-cwhy-variable-length-arrays/184401444 If you support Windows in the future, then this technique cannot be used, though Windows has _malloca() instead. http://msdn.microsoft.com/en-us//library/vstudio/5471dc8s.aspx
The calculation of sprintf result length was easy for this particular case. However generally it is not that easy. So I understand having a temp buffer on stack and using strdup is a common pattern.
According to http://www.kernel.org/doc/man-pages/online/pages/man2/execve.2.html , the memory size of environment variables we can pass to execve() is at least 32 pages. So we cannot have a hardcoded limit the count of environment variables.
So we must choose from type_a, type_c, type_d and type_e.
@hnakamur Let's choose type_e -- I am not looking for speed here; I am looking for the most simple design that represents the least fluctuation in time variance and which is the most maintainable.
Although I am against using constructs like sizeof(char *) * (env_cnt + 1)
, type_e is perhaps the most elegant design.
@kristate OK for type_e. I will modify my pull request.
Could you explain why you are against using constructs like sizeof(char *) * (env_cnt + 1)
?
Is it ok if we use calloc(sizeof(char *), env_cnt + 1)
?
Ah, that was not malloc but memcpy. OK, I will change it to a for loop.
@hnakamur I tested different ways to handle this: https://gist.github.com/3733696
Let's use the "type_b" way -- it does not fluctuate as much as type_a and has less moving parts.