h3ToGeo performance and the significance of the Digit 1 -> 15 in the H3 index.

I've been exploring this library for use in a location-based game, and it looks like a solid fit, but I would like to get some thoughts from the experts of this lib.

1. What is the significance of the Digit 1 -> 15 in the H3 index

From the information here: https://h3geo.org/docs/core-library/h3indexing

I thought that they might represent the parent cells? What is the significance of those digits in the index itself? The explanations in the docs didn't entirely convey that to someone with my less technical background.

2. H3 Performance

I'm essentially using H3 to manage a logical grid for a game with a resolution of 13 (12 hexes where just too large unfortunately). The nature of this necessitates a significant amount of kRing evaluations from players, then getting the lat/long for every hex within via h3ToGeo, and then generating some noise with the coords (To generate terrain features over the hexagons). I'm evaluating kRing with a radius of 50-210.

The majority of CPU time is spent on h3ToGeo and on noise generation. I can reduce the noise generation cost by caching generated values, but I may not be able to reduce the costs of h3ToGeo if I'm using lat/long as my lookup mechanism. When iterating of a few hundred thousand hexes h3ToGeo becomes quite expensive. (eg: ~4ms for kRing, and ~160ms for h3ToGeo)

My question here: Is there a way to increase h3ToGeo performance for batches of H3 Indexes, as opposed to getting them one at a time? Is there redundant work that is occurring for each one that may only need to be done once for a batch? If so, would it be reasonable to ask for that as a feature?

Start with the h3ToGeo and kRing entry points and the H3 indexing documentation linked in the issue. Establish whether batch conversion has reusable work and define the scope and completion criteria for any proposed batch API; the issue does not name implementation files or tests.