I don't think it would be hard to do, but doing a good job would be not be
trivial either. I wouldn't do it on top of bashdb since that would
ultimately be too slow . A cardinal rule of monitor tools should be not to
trash the thing that is getting monitored.
However I think such a profiler would use many of the same things the
debugger uses: trap DEBUG, BASH_SOURCE, LINENO, FUNCNAME, and BASH_LEVEL.
For speed I'd save the data into C arrays, by writing a builtin function,
similar to read_array/map array. But in contrast to that builtin, I don't
think it's necessary to convert the saved data into BASH structures. The
accumulated information could be written to a file at the end of program
execution. And the part that processes the data need not have anything to do
with bash.
A really great profiler would also get data on bash operations like its
array operations, substitution, subroutine call, subshell, expression
evaluations, various builtin operations and so on, but that would probably
involve hooking into the source code or working in conjunction with gprof.
As a crutch one could start with bashdb and strip it down to use just
profiler essentials, but I think you'll only go so far this way; it might be
easier just to start from scratch. It depends on how one prefers to write
programs.
On 5/31/07, Masatake YAMATO <je...@gy...> wrote:
>
> Hi,
>
> Could you estimate how it is difficult to implement profiler (like prof
> or gprof) on bash?
>
>
> Masatake YAMATO
>
> -
|
