Ralf Wildenhues wrote:
You know, I looked at sppeding up bootstrap for myself about a year ago, but couldn't figure out the cause.Don't be fooled into thinking that this patch needed less than a few months, on and off. I don't know how experts profile m4 scripts, but I first tried removing macros one by one (starting with a good guess) and ended up manually #define'ing DEBUG_SYM in m4-1.4.3 together with a form of manual statistical profiling: interrupt m4 in gdb every now and then, look where it's at. :)
I don't consider myself an expert on debugging m4 code (although I'm perhaps an expert on debugging the engine itself), and I too add manual #defines of the various DEBUG_* cpp symbols and recompile, and make judicious use of gdb to step through things. I have a vague recollection of having seen an m4 engine profiling patch and/or discussion on this list or Rene's site a few years ago. And the M4-2.0 architecture is supposed to help with writing introspection plugins. I have a profiler plugin on my TODO list for post 2.0 release.
valgrind's massif for overall memory usage profiling showed me m4 uses little heap until it starts outputting; that's what finally got me to get to the point that we needed to make use of storage in order to gain on execution time. Some off-list discussion with Stepan (thanks, BTW!) got me on the right track.
Valgrind is x86 specific unfortunately :-( I'll have to wait for Mactel
boxes before I can use it...
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
_______________________________________________ M4-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/m4-discuss
