Re: Are frozen files really that hot?

Hi Eric,

My basic question was "are there any other benchmarks for frozen 
files?". You provided a long answer to my post, but never answered my 
basic question. :( I take it the answer is "no".

 > It depends on how complex those macros were.
 >
Admittedly, the macros I write are simple, not complex. That is by 
design. I happen to disagree with the notion: "Once really addicted, 
users pursue writing of sophisticated m4 applications even to solve 
simple problems, devoting more time debugging their m4 scripts than 
doing real work. Beware that m4 may be dangerous for the health of 
compulsive programmers." I use m4 very differently from that scenario, 
which sounds like a programming nightmare. Anyway, it would make sense 
that complex macros MIGHT be sped up more by frozen files. But unless 
you have a benchmark it's more speculation than fact. I have nothing for 
or against frozen files. I just see little evidence of benefit so far, 
but do see a significant maintenance / complexity burden.

 > Yay that you were able to measure a difference for your test case.
 >
I don't know what that means. It sounds kind of flippant, like you don't 
take my post very seriously. Of course there was a difference. But it 
was disappointingly small.

> Yes.  At one point, autoconf had some O(n^2) (and even O(n^3)) macro
> definitions, some of which were encountered in the raw file and thus
> caused some noticeable delays before even getting to the user's
> configure.ac file.  The reason that GNU m4 introduced frozen files was
> because autoconf had SO MANY MACRO definitions, and that some of those
> definitions were computed definitions created by quadratic algorithms,
> where loading the frozen file really did make a difference (it's much
> faster to read in a macro's definition in frozen form than it is to
> parse one word at a time to recompute the same definition).  This was
> before GNU m4 1.4 was released.  Since then, two things have improved -
> m4's parsing speed has been improved (for example, it now uses
> getc_unlocked instead of getc, which itself had a noticeable speedup on
> processing raw files), and autoconf has moved away from O(n^2)
> algorithms (while it still defines a LOT of macros that still get loaded
> faster from frozen, it is no longer as complex to compute what those
> macros will contain).  So I'm not sure if you will see better or worse
> numbers from autoconf, but I do know that autoconf still makes heavy use
> of loading frozen files so that it gets to parsing the user's
> configure.ac sooner.

I already figured there were historical reasons why frozen files were 
introduced. My post said "Maybe frozen files were useful decades ago." 
So all the history doesn't seem relevant.

Maybe the historical reasons were bad reasons. Maybe they don't apply 
today. My guess is there were better ways to deal with those O(n^2) (and 
even O(n^3)) macro definitions. You say they are gone now, so apparently 
someone found a better way. I'm sure someone was trying to do their best 
way back when. But it's possibly they messed up, that frozen files were 
a failed experiment. Programmers make bad design decisions all the time, 
and they can persist for many years. It's possible that happened here.

As to "SO MANY MACRO definitions", I think my benchmark also had a lot 
of definitions. Again, without a benchmark, it's just speculation to 
suggest that frozen files are required to work with large numbers of 
macro definitions. It's not THAT difficult to do benchmarks. It seems 
pretty weak they spent all that time writing all those complex macros, 
but there are no benchmarks.

What are the autoconf "quadratic algorithms" you are referring to? Are 
they still around? If so, maybe there is a better approach. I would 
suggest that if there is a composite macro that is more or less general, 
widely used, and computation intensive, that would be a good candidate 
to consider using a builtin, which could potentially be much faster, 
much better, and much easier to use. But that would require an openness 
to adding builtin macros.

You totally make my point when you say "I'm not sure if you will see 
better or worse numbers from autoconf". If it's not faster, there is NO 
point to use frozen files. Perhaps without intending to, you make my 
point that there is a possibility frozen files are not so hot.

BTW, I'm sure you would not see "worse numbers". I am NOT suggesting 
that frozen files slow things down. :)

> They're not mandatory to use.  But at this point, we can't rip it out of
> m4 - there are users that depend on it.  The code is designed to not
> penalize people that aren't using it.

I never suggested frozen files were mandatory to use, so I don't get 
your point. I am suggesting is they are mandatory to maintain. And my 
guess is they add significant complexity to the software (you would be 
best placed to comment on that). And as m4 development seems more or 
less stuck based on what I read, maybe it might be a good idea to 
strategize before adding some other "feature", and to figure out how to 
get m4 development unstuck. And again, sometimes "less is more".

And I never suggested "rip it out of m4". My exact words were "might be 
deprecated at some point". I'm sure you understand what deprecated 
means. So I totally don't understand why you say "rip it out". Softwares 
deprecate things when called for. It's how you move forward.

As pointed out by another poster, I have tried to be pretty diplomatic. 
It's really great you maintain m4, I appreciate your volunteer work. But 
just my impression, you don't seem very open to the possibility of 
figuring out a better way to do things. There are perhaps valid reasons 
for that, or maybe I got the wrong impression. I write software. I love 
it when someone finds a usability problem, especially a bug, or suggests 
a possible way to improve the software. I understand some developers 
don't like that kind of input. In any case, I'm just trying to help by 
pointing out some possible ways to improve m4. Maybe it's more or less 
an echo chamber. :( Who knows? Anyway, as a user, I am just noting some 
ways m4 could probably serve the user better.

Thanks,
Daniel