Re: Surprising results when profiling Bash

[Chet Ramey]

On 8/24/24 1:46 PM, Martin D Kealey wrote:
> I've been making some tentative patches to the `devel` branch, and since I
> have a fairly large bashrc, when I compile Bash with maximal debugging
> support, its startup is ... underwhelmingly slothful.

You're seeing the memory tracing and debugging code.

> So I decided to build it with profiling enabled, and see if I'd done
> something to ruin its performance. (Short answer: nope.)
>
> What stood out immediately is that 50%~90% of the time is spent in
> mregister_free(). In theory gprof separates the time spent in subordinate
> function calls, but there's no reporting of find_entry(), perhaps because
> it's 'static', and therefore in-lined, so perhaps that's the real culprit.
>
> What puzzles me is that this is much more than mregister_alloc(), during a
> phase when *most* of the activity is defining new stuff rather than getting
> rid of stuff.

It's a simple table; alloc only has to find an empty slot, while free has
to potentially search for a while to find the associated alloc.

> I haven't tweaked anything in this area of the code.
>
> Is this expected behaviour?
> Do I need to change my compilation options, or make any other changes?

If you don't want it, compile without MALLOC_DEBUG defined. That's what
release versions do.

> I haven't delved very deeply into this code, but it does seem to be
> preoccupied with managing signals, presumably because the code isn't
> re-entrant; so I'm wondering if it would be worthwhile to investigate
> different kinds of allocators, or perhaps a different approach to handling
> signals?

It only blocks signals if it's running from a trap handler or SIGINT or
SIGCHLD are trapped. Mostly legacy stuff from when SIGINT traps were
handled immediately.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/