On systems where readdir provides d_type information, and either _rl_complete_mark_directories or rl_filename_completion_desired are set, bash is wasting a lot of time stat'ing directory entries returned by readdir() when it could have used the results from the d_type field. Unfortunately, the current interface forces this - in readline/complete.c, rl_filename_completion_function discards the readdir results by returning a single char*, and rl_display_match_list only takes a list of strings, so the readdir d_type information has already been lost.
I am considering working on a patch that provides a new interface, where completion functions return a struct consisting of a char* and d_type value, rather than the current return of a single char*. On platforms without d_type, and for completion functions that are not returning file names, the d_type field can be simply set to a placeholder DT_UNKNOWN, with no change in current semantics. Likewise, the existing APIs can be rewritten as wrappers around the new API where the d_type field is supplied as DT_UNKNOWN. But for filename completion and capable systems, using this extra information in a new API can be used to avoid a large number of stat calls, giving faster completion performance (particularly on filesystems where stat is slow). Any thoughts on whether this sounds worthwhile, or what the new API names should look like? -- Eric Blake
