Re: Would timevar be accepted in gnulib?

[Akim Demaille]

Hi Bruno!

> Le 23 sept. 2018 à 11:42, Bruno Haible <address@hidden> a écrit :
> 
> Hi Akim,
> 
>> I’m not sure I understand what you mean here.  The timers are
>> used in many places in the code, not just main().  We need some
>> global definition somewhere, and we want to iterate over them
>> when displaying the result.
> 
> OK, you have now stated the requirement.

Sorry, I did not realize my snippet was too partial.

> From an abstract point of view,
> you have a list of globally defined objects, where "list" means a data
> structure suitable for iteration. The IDs are only implementation artifacts
> for the current implementation.

I’ll be picky here, but no, the IDs are not an implementation detail.
What is an implementation details is that these ids are enums,
but of course the timers need an id.


> What I mean is that each approach has different benefits.
> 
> Approach (a) has the benefit that adding a new timevar is easy: just one
> modification in a single place. The drawback is that
>  - you need one extra source code file,

Well, since the rest of timevar would be provided by gnulib,
that file would be the only one the user would actually write.

>  - the developer needs to understand the abstraction (the fact that it's
>    an iterable list of globally defined objects was not explicitly stated),

I don’t think she needs to know that.  The implementation of
timevar needs to be able to iterate, but the typical user
just needs to 1. initialize, 2. push/pop timers, 3. print the
result.

>  - you need the artificial concept of the ID,

I don’t get this.  (b), (c) and (d) also have IDs: that of the
variables you introduced in (b) and (d), of the macros in (c).

>  - not much flexibility (e.g. you cannot process the list in reverse order,
>    you cannot define a tree or list-of-lists instead of a list).

I don’t see where this is relevant.  I guess I should have said
’set’ instead of ‘list’, the order does not matter, except for
the order used to display the result.

> Approaches (b), (c), (d) have the advantage that the abstraction is easier
> to understand, because it follows common C idioms (define structs and 
> reference
> them through pointers instead of IDs).

I disagree here.  You seem to claim that an abstraction is easier
to understand when you understand the implementation, which kind
of defeats the point of the abstraction.  If it’s clean, then
there’s no reason to know the details.

I really don’t see how (a) would be harder to grok for a C programmer.
I have absolutely no personal commitment to (a), it was just what was
in GCC when I stole this piece of code: I honestly don’t see what
makes you think it’s harder to understand.


> And they add flexibility: If someone
> wants a list-of-lists instead of a single list, it's obvious how to do the
> change.
> The drawbacks are:
> (b): To add a new timevar, two places in the code need to be touched.
> (c): none

Well, yes: it relies on even more macros, and the less there are
macros, the happier I feel :)

Amusingly, the enums of Bison’s timevar.def are uppercase
(no good reason, I just followed the pattern in GCC, but I should
change this), while your macros here lowercase :)

> (d): To add a new timevar, two places in the code need to be touched.
> 
> Note that (c), like (a), has the benefit that adding a new timevar is a
> modification in a single place.

But you’ll have a hard time defining a macro that defines a macro,
so the definition of (c) will also be way more verbose that (a).
Each definition will typically be on several lines, which I do
consider a drawback compared to some straight linear enum-like
definition.

> (d) has the further big advantage that the list can be configured at run time.
> For example, if a compiler has dynamically loadable passes (like GNU ld),

Really?  ld is dlopening some of its passes?  I had no idea.
Still: I suppose it’s to load different implementations of the
same phases, depending on the object format, or something?  In
which case they might set their timers around the calls to the
dlsyms, rather than in the dl-modules themselves.

But if that’s for an open set of plugins, yes, indeed, it won’t
do.

> this is essential.


> What do you think? Do you think the list-of-lists use-case makes sense?
> Do you think configuring the list at run time is something people may want
> to do?

You have a strong point here.  But I don’t know if there would
be actual users for such dynamic timers.

However, even if we were to move to (d), I still want to have
something like TIMEVARDEF: I don’t want to see all the complexity
of

    timevar_t tv_total = { "total time" };
    timevar_t tv_reader = { "reader" };
    ...
    gl_list_t all_timevars;
    void init_timevars (void)
    {
      ...
      all_timevars = gl_list_create_empty (GL_ARRAY_LIST, NULL, NULL, NULL, 
true);
      gl_list_add_last (all_timevars, &tv_total);
      gl_list_add_last (all_timevars, &tv_reader);
      ...
    }

in my code, there’s too much redundancy, this is too error prone.
The user will also have to remember to free the memory at the end
the program (if she’s using some memory leak detection in her test
suite for instance).


So I would argue that we should keep (a), given that it shields
us from implementation details, and we could move to (d) if
someday we think we should support dynamic timevars.