Re: Markers in a gap array

[Stefan Monnier <monnier@iro.umontreal.ca>]

BTW, I just pushed to `scratch/gl-state-bytepos` an orthogonal patch
which intends to reduce the use of `bytepos_to_charpos` by changing
the `gl_state` cache so it keeps track of the byteposition of the
boundaries of the current "chunk of `syntax-table` property".

This way RE_UPDATE_SYNTAX_TABLE can take a bytepos rather than an charpos
and convert it to charpos only when moving into a different "chunk of
`syntax-table` property".

On that previous benchmark, it works wonderfully (the implementation of
markers has basically no impact any more in that benchmark):

  | test                   | non-gc avg (s) | gc avg (s) | gcs avg | tot avg (s) | tot avg err (s) |
  |------------------------+----------------+------------+---------+-------------+-----------------|
  | bytechar               |           6.25 |       0.00 |       0 |        6.25 |            0.85 |
  | bytechar-100k          |           6.41 |       0.00 |       0 |        6.41 |            0.65 |
  | bytechar-100k-nolookup |           6.61 |       0.00 |       0 |        6.61 |            0.17 |
  | bytechar-100k-random   |           8.63 |       0.00 |       0 |        8.63 |            0.06 |
  | bytechar-100k-rev      |           7.64 |       0.00 |       0 |        7.64 |            1.48 |
  | bytechar-10k-random    |           6.79 |       0.00 |       0 |        6.79 |            0.10 |
  | bytechar-1k-random     |           6.64 |       0.00 |       0 |        6.64 |            0.15 |
  | bytechar-nolookup      |           6.63 |       0.00 |       0 |        6.63 |            0.23 |
  |------------------------+----------------+------------+---------+-------------+-----------------|
  | total                  |          55.61 |       0.00 |       0 |       55.61 |            1.86 |

Of course, that's the ideal case: that buffer has no `syntax-table` text
properties, so there's only one chunk.  In buffers with many uses of the
`syntax-table` text property, the patch may end up slowing things down
because the update from one chunk to another requires not just
a bytepos->charpos but also two additional charpos->bytepos conversions.

Still, I suspect it will usually be beneficial (the cost of going from
one chunk to another is itself significant so the extra charpos->bytepos
conversions should not slow it down unduly).

The patch has a significant FIXME that needs invesitgating (it passes
all tests, but I'm not sure it's doing the right thing).


        Stefan