Of course it depends on your app, but if you can structure it so that you store the table as a json string, fetch it at the beginning of the request, do whatever manipulations you need in memory, then json encode it and store it when you’re done, you might well find cjson is fast enough not to cause any problems. It’s pretty fast. If so then you have the benefit of the atomic shared dict and can carry on with the nice simple programming model it provides. Personally I would try it rather than assume it’ll be too slow - it might be fine, and if it’s not, then at least you’ll know for sure.
To paraphrase Joe Armstrong - first make it work, then make it elegant, and only then try to make it faster if you really need to. In this case, given that you want to take advantage of the shared dict and its atomicity (which are pretty darn good), I’d say that means: choose the appropriate data model for the environment, code it as simply and cleanly as possible, and if you *then* find you’re having performance problems with the encoding and decoding, try out different json libraries, try tweaking the structure of the data, or the access pattern to speed things up. If that still doesn’t work, maybe the shared dict isn’t the right way, maybe you should be using redis or something like that. Either way, making a simple test case and whacking it with a load test tool like siege or httperf (or even ab, though remember it lies) will show you pretty quickly whether it’ll do what you need it to do. It’ll have been worth it either way.
I often find myself trying to second-guess which route will be better, so I can avoid spending the time having to come back and do something again if route #1 doesn’t work out. In one way that makes a lot of sense - but just as often it turns out a lot better to try out the simplest realistic test of both routes and measure, because then you know, so you’re not relying on intuition and the net time and effort gain is usually pretty good. (Obviously over time intuition improves based on all the testing, so in the long run I find it also helps me not having to test *quite* so much :-))