Re: 32-bit profiling counts?

[Wolfgang Laun]

Dear gawk maintainers,

I'd treat this with  low priority. Considering the time the minimal case
ran on my machine, it must be a real monster of a program that makes the
count of some inner loop overflow 32 bit. The goal of profiling is to
identify hot spots of high execution frequency. With a count beyond
0x8000000 we are in some extremely frequently executed code, and the
"nuances" beyond such count values shouldn't matter any more. If you have
ascertained that such an innermost loop isn't wasting cycles, you may look
elsewhere. Most of the time, it is the quality and order of the outer loops
that exacerbates what happens within.

Wolfgang



On Sun, 7 Jun 2020 at 08:18, <arnold@skeeve.com> wrote:

> "Andrew J. Schorr" <aschorr@telemetry-investments.com> wrote:
>
> > One could certainly hardwire a 64-bit type in that field, but I can't
> find
> > any instances of that in the gawk codebase, for reasons not obvious to
> me,
>
> The code predates my switch to 64-bit versions of Linux as the
> development platform.
>
> > and we'd have to review the impact of changing that type since the field
> > is used for other purposes in different contexts.
>
> Yes, exactly.  Also the possible increase in the size of the NODE
> struct.
>
> I suspect that moving to an unsigned type would break things,
> but that moving to 64 bit long would cause less breakage. We'd
> still have to check if the values gets printed with the right
> format in all the right places.
>
> Arnold
>