So I go into a discussion about the performance impact of using Shared Memory Objects. For those not familiar with the concept, it’s basically an object instance that can be accessed by all users logged onto the same application server.
Obviously there will be some performance costs, but the question we were trying to answer is how big a penalty it incurs. In the end I wrote a little test program and thought I’d share the results.
- Accessing a Shared Memory Object component in readonly mode is a little over 50 times slower than using an instance in session memory.
- Accessing the same object in update mode is more than 5 times slower than readonly mode, in total 300 times slower than a regular object instance.
I tested a million method calls using a standard call, readonly and update mode. Each iteration will instantiate / attach the object.
UPDATE: I also added another test shm_attach_once, where the instance is attached before the loop. This demonstrates that once attached, the performance is pretty much the same as a regular object.
If anyone is interested in my test source, it’s over here. Note that it is not a best practice example but just a quick and dirty implementation with minimal code, no error handling or conditional instantiation etc.
My takeaway from this is:
- For readonly access, I wouldn’t worry about performance. A common reason to use Shared Memory Objects is to provide features that would otherwise be implemented in the DB, so it will always be faster than that, and is still a very fast way to persist data across sessions.
- For write access it’s wise to put a little more thought into it. Don’t use attach_for_write unless you need it. Use common sense and don’t do it inside a repeated piece of code such as loops; instead, attach once beforehand and commit after the loop. Stick to that and the 55ms that it takes on my laptop is unlikely to be a dealbreaker.