From: Rocky B. <roc...@gm...> - 2007-05-31 08:37:16
|
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 > > - |