Dylan K. Taylor fbf325a283 Drop array-of-type functions (for now) ...

While these functions do, in themselves, provide a performance advantage
over writing a plain array, this doesn't consider hidden costs.

- When encoding a chunk palette, the palette has to first be converted
  from a native array to a PHP array just for this extension to accept
  and turn back into an std::vector. This makes no sense and is
  needlessly costing performance.
- Encoding chunk palettes in batch also requires allocating a *second*
  array, just for this extension's consumption, because the values in
  the palette have to be transformed before encoding. We could modify
  the arrays in-place, but it's optimising the wrong problem.
- Generally speaking, the places that actually benefit from these
  functions are either cold paths, or they'd benefit more generally from
  not using PHP arrays, or both. So it's hard to make the case for
  optimising this particular use case.
- The cost of turning PHP arrays into std::vector in this extension (a
  necessary step) is rather high.

The overarching theme here is that arrays need to be avoided everywhere
where performance or memory usage is an issue, and having this extension
accept and especially *return* them is hobbling consumers of the API.

The logical next step would be to add classes like IntArray, LongArray
etc to act as a thin PHP wrapper around native uint32_t[] etc, and then
have array APIs in ext-encoding that would accept and return these
specialised classes instead of PHP arrays. However, this is an endeavour
I'd prefer to undertake speculatively *after* getting the lion's share of
the benefits from ext-encoding's regular (non array) functions, given the
rather limited benefit expected anyway (we barely have any use cases for
writing direct array-of-type anyway). In the meantime, having these
barely-useful functions in the API would give us backwards-compatibility
constraints if they made it to a stable release, which would be an
obstacle for implementing actually good array-of-type functions later.

So, bye-bye array-of-type, for now...

2025-09-11 17:04:47 +01:00

17 KiB

Raw Permalink Blame History

View Raw