[Bash-completion-devel] Roadmap proposal

[Ville Skyttä]

On Monday 16 February 2009, Freddy Vulto wrote:

> Sourcing an average example file a hundred times, e.g. `contrib/gkrellm'
> takes about .155s:
>
>    $ time for (( i=0; i < 100; i++)); do . contrib/gkrellm; done
>    real	0m0.155s
>    user	0m0.148s
>    sys	0m0.008s
>
> I figure main bash_completion defines 247 functions:
>
>    $ grep '^[^[:space:]]\+()' bash_completion | wc -l
>    247
>
> So, should we "split every command", say 180 functions, that's gonna add
> (1.8 * .155 = .3s to bash_completion, but by removing functions from the
> main file we save at least .3s as well.
>
> Conclusion: overall performance is not going to make bash_completion much
> slower if "every file is splitted into its own file", i.e. moved from
> `bash_completion' to `contrib'.

I think the results would be somewhat different in cases where the small files 
weren't cached in memory but had to be actually read from disk (for example I 
believe your contrib/gkrellm loop above actually reads the file from disk 
only once).  I'd be surprised if reading one largish uncached file wouldn't 
be much faster than reading hundreds of small uncached ones.

Dunno how often the uncached accesses happen though, hopefully not that often, 
and how that affects the total time spent loading the whole shebang.  But I 
think the uncached scenario should be measured anyway before jumping to a 
conclusion...  "sync; echo 3 > /proc/sys/vm/drop_caches" could be helpful.

For example, on my box:

$ mkdir foo
$ for (( i=0; i < 100; i++ )); do cp contrib/gkrellm foo/$i ; done

# cached, right after the above copying:
$ time for (( i=0; i < 100; i++ )); do . foo/$i ; done
real    0m0.081s
user    0m0.043s
sys     0m0.005s

# uncached
$ su -c "sync; echo 3 > /proc/sys/vm/drop_caches"
$ time for (( i=0; i < 100; i++ )); do . foo/$i ; done
real    0m0.371s
user    0m0.045s
sys     0m0.015s

(I'm too tired to make any conclusion from that right now ;))