[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
- Surprising results when profiling Bash,
Martin D Kealey <=