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
