I was thinking about one source of slowness in bashdb - reading in the
script file to be debugged.
We read in the source file in order to be able to accurately display
the source code that bash is running against. If bashdb used an
external command like "head", "tail", or "pr", the file could be
changed in the course of the run of the program. (In fact, I often do
this.) Bash however would not pick up the line changes until the
program is restarted. Since we rely on line numbers to set
breakpoints, it is helpful for the line numbers to match those that
bash reports.[1]
In order to speed up reading source files into arrays, I've been able
to create a built-in routine that does just that. Testing using the
28,000-line configure script for bash, the difference in time was
something like 9 seconds (real time) for the builti-in routine versus
40 seconds for what is currently used -- a loop over each line of the
file with a eval of a read.
The downside of this approach is that the built-in routine would only
run for the the version of bash it is compiled against, and to compile
the source I guess folks would need the bash sources around. It's
possible this routine might have to get changed from version to
version.
My experience with writing built-in routines is that if something is
wrong, the routine or bash dies without much information, and I
haven't been able to figure out how to easily debug such built
ins. This makes a more highly optimized routine a bit tougher - right
now I just call a routine to do repeated array assignments; for each
assignment, a function lookup of the variable name is made; and on
each line flags are tested to see if the assignment is okay (i.e. not
read only).
To compensate for the difficulties of having sources to compile
against, I suppose the debugger could have two versions of some
routines - some that work with the built in and some that don't.
Lastly, in the back of my mind I think it would be beneficial to push
more of this into bash itself - if there is not already a way to do
this. (I think the last time I looked I couldn't find something simple
without changing code.) That is, it woudl be nice if one could ask
bash for the source code for a given file and line -- it keeps some
sort of internal representation of it which it unparses when it does
set -x tracing.
And the notion of asking more of bash is related to another big source
of slowness in the debugger: traps get called after every statement
just to figure out if it's time to enter the debugger. (Most of the
time the answer is no). A better organization would be to register a
line or function name to the bash and have bash do at least
preliminary checking.
- - -
[1] If one sets a breakpoint on a function, internally it gets turned
into a file/line number. So if one tries to debug this script:
line=1;
line=2; dbg() { echo "dbg called"; }
line=3;
dbg
exit 5
You won't be able to set a breakpoint on dbg until line 3 is reached
because dbg isn't defined until then. And if one then restarts, an
continues, the breakpoint occurs before the assignment line=2. I
suppose this is a bug.
|
