Ahh, smart move. So it is best to decode json from the same instance and make sure that instance exists the entire game to prevent leaks.
I adapted your asset a bit to be able to handle ds maps and ds lists. There is currently a depth limit/bug in json_decode that cause deep json to fail when decoding. (I adapted your asset by adding a special struct that cointain a ds map and special array that cointain the ds list and when adding the keys and vals to the parent json node it check if it is the special struct or array and extract the map or list and add it instead of a struct or array. Like "mark" this struct as ds map and mark this array as ds list. It is only for the tj_decode as a workaround for the buggy json_decode. json_encode don't have a depth issue).
Structs are fine in most cases, but they don't allow you to contain self references (cause infinite loops when encode/decode). I needed my data to hold a pointer/reference to the parent node, next node and previous node in a tree structure. So you can walk/access nodes backward and forward from each node. Wish GM got a native ds_tree structure (but nesting ds list and maps works fine with ds_list_mark_as_map and ds_map_add_map...).
Viewing post in _keys and _vals ds lists never destroyed?
Ahh, smart move. So it is best to decode json from the same instance and make sure that instance exists the entire game to prevent leaks.
Pools are global variables, you don’t have to do anything specific.
If you are replicating the regular json_encode/decode, you don’t need pools since you can be adding data to the new map/list directly.
Self-references can be handled by limiting max depth or forming a <ref>->index map (so that non-first references would be saved as “ref#X”, for example)