[Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 7d45595493e1f830a3ddbdff845f05ce5a0bc696

[Guillaume Rousse]

Le 07/11/2010 10:46, Ville Skyttä a écrit :
> On Saturday 06 November 2010, Guillaume Rousse wrote:
>> Le 26/10/2010 20:16, Ville Skyttä a écrit :
>>> On Tuesday 26 October 2010, Ville Skyttä wrote:
>>>> On Tuesday 26 October 2010, Guillaume Rousse wrote:
>>>>> I'm still interested in merging remaining similar patches (for rpm
>>>>> database completion,
>>>>
>>>> I don't personally find rpmdb completion too slow to warrant it being
>>>> off by default.
>>>
>>> Forgot to include some representative numbers about this; on a box with
>>> Athlon
>>
>>> 64 3200+, 3GB memory, and rpmdb on an SSD disk:
>> 'SSD' and 'representative' together :) ?
> 
> Well, if that's the way you want to put it, shrug.  The numbers are 
> representative in my experience.
> 
>> Sure, on any modern desktop or laptop, everything is fine. But just try
>> on some 4/5 years-old outworked server, for instance... Everytime you
>> hit <TAB>, just because you are used too on your own workstation, you
>> are entitled to 2/3 second timeout.
> 
> Here are some numbers from such a server box (BIOS from 2004, box probably 
> even older than that), P4 2.8GHz, 1.5GB memory, slow PATA disk, running CentOS 
> 5.5 i386.  The first time one of these commands are executed takes a bit of 
> time (even a bit more than the 3 seconds you mentioned), but after that the 
> numbers look like:
> 
> $ time rpm -qa --nodigest --nosignature --qf="%{NAME} " >/dev/null
> 
> real    0m0.119s
> user    0m0.072s
> sys     0m0.047s
> 
> $ time rpm -qa --nodigest --nosignature --qf="%{NAME} " "x*" >/dev/null
> 
> real    0m0.113s
> user    0m0.069s
> sys     0m0.045s
Interesting. Even on my own shiny tablet laptop (core2 duo, 1.6Ghz, SSD
disks), I can't achieve such results:

[root at beria guillaume]# time -p rpm -qa --nodigest --nosignature
--qf="%{NAME} " >/dev/null
real 0.26
user 0.19
sys 0.06

There is probably a technical difference either in bdb or in rpm
between Redhat and Mandriva explaining the difference. That's an
interesting track to explore for me. But my point was old hardware, here
are the results on two old servers:

2 * P3 600Mhz:
[root at cthulhu ~]# time -p rpm -qa --nodigest --nosignature --qf="%{NAME}
" >/dev/null
real 1.01
user 0.68
sys 0.33

6 * P3 700Mhz:
[root at ryu ~]# time -p rpm -qa --nodigest --nosignature --qf="%{NAME} "
>/dev/null
real 0.80
user 0.57
sys 0.21

OK, those boxes are 10-years old, and probably not representative at
all, but they still exists.

Also, the values are still two orders of magnitude higher than a simple
'cat /var/log/rpmpkgs', making live rpm database completion 100 times
slower as completing from daily dump files. Indeed, hardware evolution
make this difference less and less noticeable. I can reconsider my
position here.

However, there was a second completion in my list: remote path
completion through scp. Here, whatever your hardware, you also depends
on remote hardware, and on network congestion. Morevoer, there is no
speedup at second attempt. All this concurs to make it a 'potentially
slow' completion, hence my suggestion to make it disabled by default.
Morevoer, this would be consistent with a switch we already have for CVS
(COMP_CVS_REMOTE). That's my second patch.

>> Hence my point to make them at least
>> configurable, and eventually disabled by default.
> 
> Configurable ok if people insist, disabled by default -1.
Unfortunatly, I also realized than as long as we don't have a
standardized configuration process, we can't do it easily. Unless we use
an ugly mix of 'enable-if-defined' and 'disable-if-defined' environment
variables :/


>> Also, I'm not very happy with the name you used for the new avahi
>> switch, as it's not very consistent with other variables names sofar:
>> COMP_IWLIST_SCAN,
> 
> That's not documented in doc/bash_completion.txt BTW.
Indeed.

>> COMP_CONFIGURE_HINTS, COMP_TAR_INTERNAL_PATHS all use
>> a <command>_<verb> or <command>_<object> pattern, whereas
>> COMP_KNOWN_HOSTS_WITH_AVAHI use <objects>_with_<command> pattern. I'd
>> rather use something as COMP_AVAHI_HOSTS or COMP_AVAHI_KNOWN_HOSTS, for
>> instance.
> 
> That would be inconsistent with all the other variables (except 
> COMP_IWLIST_SCAN which IMO would be better named COMP_IWCONFIG_IWLIST_SCAN) 
> because it places "avahi" at the beginning and this variable does not control 
> avahi completions, it controls known hosts completions.  All the things that 
> control something should have a common prefix ("COMP_" alone does not count) 
> so they group naturally in sorted listings making them easier to look up (e.g. 
> docs, env | sort), and all the existing variables (except COMP_IWLIST_SCAN) 
> follow that naming.  And we already had COMP_KNOWN_HOSTS_WITH_HOSTFILE.  The 
> WITH in COMP_KNOWN_HOSTS_* might be noise, but... meh.
That make sense, and I wasn't aware of COMP_KNOWN_HOSTS_WITH_HOSTFILE
existence, actually.

What about the following naming scheme then ?
COMP_IWCONFIG_WITH_IWLIST
COMP_KNOWN_HOSTS_WITH_HOSTFILE
COMP_KNOWN_HOSTS_WITH_AVAHI
-- 
BOFH excuse #360:

Your parity check is overdrawn and you're out of cache.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4251 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20101107/70629fa4/attachment.bin>