Idea

For objects, if the object is present on reset, you can store the object's ID and use the Object format. This will store a number unique to the object, but show the path. You can control how much of the path to show using the Object Format Max Depth variable.

For all other string categories, you should use the String type field on the stats collector. Stats collectors always use the BUNDLE_FIELD_TYPE_VARCHAR for string fields. This field type only stores one instance of each unique string. Each entry in the bundle stores a 4-byte index into the list of unique strings. This allows for any length of string, and is also very memory efficient.

As for speed, yes, technically reading/writing a number is usually faster. However, the difference is trivial. I made this test model that causes 2 million events, where a stats collector writes a single row/value for each one. Here are the times I got on my machine for this model:

• Just the model (no stats collectors) - 13.59 seconds
• Model + Writing 2 million number values - 17.43 seconds (+3.84 s, 520k values/s)
• Model + Writing 2 million string values - 18.08 seconds (+4.49 s, 445k values/s)

So using a string field cost 0.65 seconds extra to write 2 million values. In those models case, it also cost less than 1 kb of additional memory use string vs number data.

In a real model that records 2 million data points, the model time will usually be much, much greater than 14 seconds. Suppose it takes 2 minutes to run that model enough to gather 2 million points of data. If we make it so that people record numbers instead of strings, we would save the user 0.65/120, or 0.5% of their model time. Most people won't even notice that difference.

teststringfields.fsm