autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: m4_warn test fails, removing autom4te.cache helps


From: akim
Subject: Re: m4_warn test fails, removing autom4te.cache helps
Date: Sun, 5 Aug 2001 21:06:38 +0200
User-agent: Mutt/1.3.18i

On Sun, Aug 05, 2001 at 03:56:07AM -0400, Pavel Roskin wrote:
> Hi, Akim!
> 
> > > Removing autom4te.cache between autoconf invocations fixes the test, but I
> > > believe that the actual problem is in autoconf, not in the test.
> >
> > Please, see the related patches in autoconf-patches.  I'm not sure what
> > to do here.
> 
> I personally don't feel good about caching, especially if it brings
> problems that are hard to solve.

I don't think they are that hard to solve, well, at least up to now.
They are challenging :)  And since I really believe the future is in
traces, it's important, IMHO.  A lot of the GNU build tools will depend
on them, and currently autoconf is way toooo slooooow....

> I don't want you to spend your precious time fixing and improving trace
> caching - your time outweighs the time saved in all autoconf and
> autoheader invocations across the world.

:)

Thanks for your kinds words.  Byt you know, OTOHG, I really need to get
some pleasure from time to time.  Merely fixing bugs, trying to explain
things etc. is exhausting :(  It's yet noather of those periods where I'm
ready to drop the maintenance...

Existenctial questions (was I right) and this kinda stuff.

Still, today, I would like to promote Autotest, M4sh (with the addition
of Ad'HoC and so on), so I still have some faith.  I don't want to leave
before autosystem and specializing macros.

> Maybe you could disable autom4te.cache by default (like config.cache) and
> play with it when you want to, not when the testsuite fails.

Maybe we will for the release, but I believe our community is ready to
experiment.  And conversely, I believe the current failures, and the other
problems I envision are really benign.  I don't think missing some warnings
on the second run when you changed your -W is a bad failure (that's
what the failure is actually saying).

I'm having some piece of fun with M4 currently, trying to understand the
slowness of Autoconf.  I equipped my copy of M4 with dumpstat which
counts the number of invocations of a macro.  I include the results below
for information.  Guess what macro is the most used...  It's fun :)

But I hardly believe it's the slowest macro.  I would like to implement
profiling in M4, but my knowledge is poor (I don't even know how to
get some precise time from the system, counting by second is certainly
not fine enough, and worse yet, I don't even have the slighest idea of
how to get durations that are not penalized by the profiling itself.
Actually, I don't even know if that matters, maybe the figures comprising
the profiling itself is relevant enough to understand where the heck
we are losing that much time.  I do have my idea: the call stack.  Once
I'm sure that's the culprit, I will proceed and implement in M4, hoping
that some day more services from M4 will help us run a better Autoconf.
BTW, it helped me discoever some M4 1.4p bugs, and worse yet, some
incompatibilities that would break the current Autom4te based system
:(  ).

Here are the figures on the Fileutils.  Bad news: it does use syscmd, 
to `test -f' the presence of regex.h in the package.  <Tom>Bummer</Tom>.

dnl: 198920 invocations
m4_shift: 119196 invocations
m4_ifdef: 88623 invocations
m4_builtin: 57043 invocations
m4_if: 48845 invocations
m4_ifndef: 47377 invocations
m4_define: 32184 invocations
m4_pushdef: 27215 invocations
m4_popdef: 27210 invocations
m4_defn: 18459 invocations
m4_eval: 15327 invocations
m4_ifval: 14054 invocations
__line__: 12649 invocations
__file__: 12649 invocations
m4_car_quoted: 11610 invocations
_m4_divert: 11451 invocations
m4_provide: 9733 invocations
m4_regexp: 7066 invocations
m4_expansion_stack_push: 7026 invocations
m4_expansion_stack_pop: 7026 invocations
m4_indir: 6698 invocations
m4_patsubst: 6649 invocations
_m4_foreach_quoted: 6305 invocations
len: 5752 invocations
m4_divert_push: 5535 invocations
m4_divert_pop: 5533 invocations
_m4_divert(GROW): 5496 invocations
m4_location: 5387 invocations
_m4_defun_pro: 5387 invocations
_m4_defun_epi: 5387 invocations
AC_PROVIDE: 4202 invocations
AS_LITERAL_IF: 3852 invocations
m4_default: 3797 invocations
AS_MESSAGE_LOG_FD: 3648 invocations
m4_provide_ifelse: 3520 invocations
_m4_shiftn: 3042 invocations
m4_n: 1770 invocations
m4_ifvaln: 1770 invocations
AS_ESCAPE: 1660 invocations
m4_translit: 1524 invocations
m4_require: 1449 invocations
m4_changequote: 1428 invocations
_AS_ECHO_UNQUOTED: 1350 invocations
m4_len: 1323 invocations
_AS_QUOTE_IFELSE: 1318 invocations
_AS_QUOTE: 1318 invocations
AS_MESSAGE_FD: 1195 invocations
_AC_LANG: 1158 invocations
m4_car: 1047 invocations
m4_shiftn: 963 invocations
m4_assert: 963 invocations
AS_IF: 868 invocations
AS_VAR_GET: 835 invocations
_AC_LANG_DISPATCH: 821 invocations
_AS_ECHO: 720 invocations
m4_split: 714 invocations
m4_strip: 699 invocations
m4_normalize: 699 invocations
m4_flatten: 699 invocations
m4_quote: 673 invocations
_m4_foreach: 673 invocations
_AC_RUN_LOG: 566 invocations
_AC_EVAL: 565 invocations
m4_text_wrap: 553 invocations
m4_foreach_quoted: 553 invocations
AH_OUTPUT: 550 invocations
AS_TR_CPP: 536 invocations

Attachment: sorted.gz
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]