file.seek( len(table.json) - tail) for faster inserting

[nikhil-swamix]

Sample Code:
{"_default": {"1": {"id": 1242672, "status": "applied"}, "2": {"id": 1244142, "status": "applied"}, "3": {"id": 1238254, "status": "applied"}, "4": {"id": 1244331, "status": "applied"}, "5": {"id": 1237366, "status": "applied"}, "6": {"id": 1240860, "status": "applied"}, "7": {"id": 1240613, "status": "applied"}, "8": {"id": 1242849, "status": "applied"}, "9": {"id": 1237535, "status": "applied"}, "10": {"id": 1240675, "status": "applied"}, "11": {"id": 1246575, "status": "applied"}, "12": {"id": 1238059, "status": "applied"}, "13": {"id": 1242863, "status": "applied"}, "14": {"id": 1246500, "status": "applied"}, "15": {"id": 1245248, "status": "applied"}, "16": {"id": 1245969, "status": "applied"}, "17": {"id": 1244862, "status": "applied"}, "18": {"id": 1243440, "status": "applied"}, "19": {"id": 1246730, "status": "applied"}, "20": {"id": 1246583, "status": "applied"}}}

Suggestion:
i assume the internal mechanics are using json load for R/W. but what i believe is seeking towards end of file and scanning for id , "20", and cut }} add , "21": {...}}} will be faster.

@msiemens what do you think?

[msiemens]

There are tons of way to change the performance characteristics of TinyDB 🙂 It's all about trade-offs. Right now, it's a really simple mechanism for reading/writing data. The change you propose would work for some scenarios, but would need special care, e.g. if dealing with nested data (say, something like {"id": 123456, "entries": {"20": {"foo": "bar"}}}). Here, the heuristic you proposed would not work, at least not without more processing.