> Has anyone else encountered this problem? Solutions? Theories? Guesses?
Sfront just calculates the widths several times, in broad stroke like
the (1), (2), (3), (4) in your first paragraph. In particular, see the
"widthupdate" recursive function in treeupdate.c, and note that its
called for the purposes of determining instr widths in postparse.c,
and then called again in optmain.c to determine the final widths
before optimization begins. The few other calls of widthupdate in
the code are for little expressions, like the send() statement
expressions for parameters.
Sfront's Makefiles and Linux binaries are shipped with the debug option
on (as well as the conservative -O2 optimization), and its running time
is such a small fraction of gcc's running time that any effort to
optimize "audio startup latency" for sfront would start with profiling gcc
and changing the code sfront generates to compile faster, not by
by optimizing away tree passes to make sfront itself run faster ...
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:55 EST