String table sizing - rational?

[kalmard0]

I'm working on an ink-based game. I have a function in the game that creates a character sheet, listing the player's posessions. There are about 30 possible items (global boolean variables) and the text is generated dynamically depending on whether the player has each item.

This funcion, when more than ~10 items are present, crashes inkcpp due to the string table filling up.

Of course I can increase the size of the string table and call it a day, but I would like to understand this problem in a bit more detail.

1. Is this expected behavior? Or is it possible that I messed up my code or there's a memory leak?
2. What's the overhead of the string table's size? Are we talking bytes per unit, or kilobytes per unit?
3. Why not have a significantly larger default size?
4. What size should I set to ensure that this never-ever-ever can happen in my game?

As a short-term solution, I'm planning to send a pull request that allows overriding the default size via a define. But if you'd rather just me set a significantly higher default size, that works too.

The ink script is proprietary, but if absolutely needed, I can spend some time creating a derived version as a proof-of-concept for this crash.

[JBenda]

Thanks for your investigation, regarding your questions:

1. The string_table stores all strings used for global/local variables and string fragments touched since the last choice.
   → if you execute "a lot" of code in between choices it is expected behavior
2. the string table has nearly no overhead, it is stored as a balanced binary tree (AVL) and has therefore an overhead of a couple of bytes for weight metric and pointer (around 24 bytes? If I must guess)
3. (, 4) The default size was set when the project was still used for a 3DS project, which had quit harsh memory constraints and was not touched since then. When we implemented the dynamic allocations (negative configuration variables) we must have overlooked it. An estimate is difficult to make, without knowing the code base. But it should support dynamic resizing anyway.

So I will add the same dynamic allocation logic for the string_table as used by the other stacks and containers. In addition and regarding #102 a possibility to get the current "usage" of the different container (most likely capacity and current size).

In this go, I will finish your work on #107 to compile with C++17.

Thank you kindly for your input, and if any questions remain, feel free to ask.

[JBenda]

You could now use the "globals->statistics()" function to check if you (or inkcpp) have a memory leak or if you just need a larger size. See in inkcpp_cl here and here for an example usage.