Re: [Qemu-devel] [PATCH 5/6] json: Eliminate lexer state IN_ERROR

[Eric Blake]

On 08/27/2018 11:40 PM, Markus Armbruster wrote:

> > >    typedef enum json_token_type {
> > > -    JSON_MIN = 100,
> > > -    JSON_LCURLY = JSON_MIN,
> > > +    JSON_ERROR = 0,             /* must be zero, see json_lexer[] */
> > > +    /* Gap for lexer states */
> > > +    JSON_LCURLY = 100,
> > > +    JSON_MIN = JSON_LCURLY,
> >
> > In an earlier version of this type of cleanup, you swapped the IN_ and
> > JSON_ values and eliminated the gap, to make the overall table more
> > compact (no storage wasted on any of the states in the gap between the
> > two).
> >
> > https://lists.gnu.org/archive/html/qemu-devel/2018-08/msg01178.html
> >
> > Is it still worth trying to minimize the gap between the two
> > sequences, even if you now no longer swap them in order?
>
> You caught me :)
>
> Eliminating the gap actually enlarges the table.

Rather, switching the order enlarges the table.

>  I first got confused,
> then measured the size change backwards to confirm my confused ideas.
> When I looked at the patch again, I realized my mistake, and silently
> dropped this part of the change.

The size of the table is determined by the fact that we must initialize 
entry 0 (whether we spell it IN_ERROR or JSON_ERROR), then pay attention 
to the largest value assigned.  Re-reading json_lexer[], you are only 
initializing IN_* states, and not JSON_* states; swapping JSON_* to come 
first enlarged the table because you now have a bunch of additional rows 
in the table that are all 0-initialized to JSON_ERROR transitions.

So at the end of the day, leaving IN_* to be first, and putting JSON_* 
second, makes sense.

The question remains, then, if a fixed-size gap (by making JSON_MIN be 
exactly 100) is any smarter than a contiguous layout (by making JSON_MIN 
be IN_START_INTERP + 1).  I can't see any strong reason for preferring 
one form over the other, so keeping the gap doesn't hurt.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org