bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Surprising results when profiling Bash


From: Martin D Kealey
Subject: Surprising results when profiling Bash
Date: Sun, 25 Aug 2024 03:46:45 +1000

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.

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.

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?

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?

-Martin


reply via email to

[Prev in Thread] Current Thread [Next in Thread]