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 c...@case.edu http://tiswww.cwru.edu/~chet/
