On Sat, Dec 13, 2014 at 02:08:08PM -0300, Raphaël wrote: > On Fri, Dec 12, 2014 at 08:42:27PM -0400, Peter Cordes wrote: > > I guess my thinking is that when we can bring COMPREPLY down from 100k > > to 50k items with sort -u, it's not a bad idea. > > Worth noting that `sort` use temporary files (= $TMPDIR filesystem > accesses). > Not sure about bash's compgen.
sort doesn't use temp files if the input isn't THAT big. for i in {0..1};do apt-cache pkgnames;done | strace -efile sort -u >/dev/null I only see it open files in /tmp with more than 2 repeats of the package list. (each about 43k items on Ubuntu trusty). My thinking is that if bash allocates a lot of memory, and it then allocates some small things that it will keep for a while, even freeing the big chunk doesn't fully get you back to where you were before. You might keep memory fragmentation and bloat to a minimum by not passing giant COMPREPLY arrays back to bash for it to sort and uniq, when the list is likely to be big enough to warrant piping the data through sort(1). And like I said, I'm inclined to be cautious, because I saw bash die once, with an error message about memory, maybe corruption, can't remember. My system doesn't randomly crash, so it's unlikely to be a hardware error. Ubuntu 4.3.11(1)-release. I guess I should try to reproduce this sometime. -- #define X(x,y) x##y Peter Cordes ; e-mail: X(peter@cor , des.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel