On 6/6/07, Alex Boisvert <[EMAIL PROTECTED]> wrote:
On 6/6/07, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > But exactly why would an in-memory process ever be serialized? That should > be down to 0%. I think that's pretty much what Matthieu was saying; there's a quick & easy optimization to be made here that's not dependent on refactoring thread/transaction demarcation.
There are certain state storage optimization strategy that will work very well for in-memory (where you optimize for CPU), but will not work very well for persistence (when you also care about scalability and the database). Given that in-memory processes don't want to store anything, trying to find an optimal strategy for both is pointless, it actually takes away from optimizing persistent processes. So I suggest we split the discussion. For in-memory processes we already know the optimal storage strategy: store nothing. Caching, transactions, etc are either irrelevant or inconsequential. And for persistence processes, we need to start running benchmarks, so we can talk about the best persistence strategy for those. It's persistence processes where we should find strategies to improve
> performance/scalability by reducing serialization cost. Yep, the flyweight pattern <http://c2.com/cgi/wiki?FlyweightPattern> would be most efficient here (also suggested by Matthieu in different words)
That only works if you have a finite number of states. assaf alex
