ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Ode Performance: Round I
Date Wed, 06 Jun 2007 23:03:13 GMT
On 6/6/07, Alex Boisvert <boisvert@intalio.com> wrote:
> On 6/6/07, Assaf Arkin <arkin@intalio.com> 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

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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message