Performance of _bash-preexec_'s DEBUG trap

[gaelicWizard]

Expected Behavior

I expect a DEBUG trap to have some minor performance impact that largely doesn't matter for an interactive shell.

Current Behavior

Using the below contrived example, which started as troubleshooting a parameter substitution performance issue:

• Five seconds with blank trap
• Fifteen seconds with : (no-op) trap
• Five minutes with __bp_preexec_invoke_exec function!

Honestly, doubling performance cost of every simple command would be acceptable and I wouldn't notice. But, it seems that having any DEBUG trap in Bash causes a simple echo to triple in cost. A nontrivial function for the trap? bananas.

Possible Solution

• Handle setting/unsetting the DEBUG trap only when $preexec_functions has contents?
• Aggressively optimize performance of trap function?

Context

I was debugging a string handling performance issue and accidentally tested the DEBUG trap and...wow...

Steps to Reproduce

mybug="$(trap -p DEBUG)"
time for debug in 'trap - DEBUG' 'trap "" DEBUG' 'trap ":" DEBUG' "$mybug"
do
    eval "$debug"
    echo 'echo' "(DEBUG: $debug)" >&2
    time for i in {1..999999}; do echo "$i"; done >/dev/null
done

Your Environment

• Bash-it version used: (1) my branch, (2) master branch, (3) without loaded at all.
• Bash version: 3.2, 4.2, 5.1.8
• Operating System and version: Mac OS X 11 "Big Sur", CentOS 7.7 (Core)

[NoahGorny]

Hmm, this seems like an issue that affects bash-preexec globally, not just a problem in Bash-it.

We should probably migrate this problem to the bash-preexec repo instead.

[gaelicWizard]

Yes, I'll alsö be submitting an issue upstream! There have been numerous complaints of minor performance issues with Bash It and this may be related, so we should at least track it if not do something in Bash It to ameliorate the impact.

Of course, besides contrived examples it may not really impact interactive performance anyway. I need to test more.