embedlets-developer

[Embedlets-dev] Making progress on the TINI....

[Andrzej J. T. <an...@ch...>]

It was bugging me, so I did some investigation, and found that one particular 
operation was killing the TINI performance, and that was accessing various 
component property values during the event propagation process.  I refactored 
that so that Components (eg. Embedlets) cache their static values in instance 
variables (things like the unique ID, description, version, etc.) and also 
refactored how Lifecycle state was get/set in a similar manner.

Here were the results, comparing async and sync event propagation (all values 
in events/second)  before and after the refactorings:

PLATFORM        ASYNC      SYNC (Recycled)   SYNC (Non-Recycled)

TINI (before):            8                 13                          143
TINI (after):             12                 71                          133

As you can see, the Async speed improved by 50%.  The Sync speed using 
recycled event instances (so only one is ever created) was markedly improved 
by the refactoring. The Sync (Non-recycled) slowed down a trifle due to some 
other refactoring that I put in place to improve the Embedlet spec interfaces 
a bit, but the net loss in speed was only about 7% (and those structural 
refactorings were necessary).

I figure the SYNC (Non-Recycled) is running about as fast as the poor TINI 
can go, and though there might be some minor tweaking that could possibly 
help a bit, that's about all she wrote.  With the new refactorings, the SYNC 
(Recycled) path is probably approaching optimum as well.

However, the Async is still quite disappointing.  Sure it's using threads and 
thread context switches, but I think it should be a bit closer to the  SYNC 
(Recycled) performance.  My gut feel is that this can probably be improved a 
fair bit by optimizing the queue structures (away from generic Vectors and 
Hashtables to more customized versions that are specifically tuned to the 
access patterns that async event propagation produces).  So there is still 
lots of room there I think.





Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

RE: [Embedlets-dev] Making progress on the TINI....

[Christopher S. <cs...@oo...>]

> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> It was bugging me, so I did some investigation, and found that
> one particular
> operation was killing the TINI performance, and that was
> accessing various
> component property values during the event propagation process.
> I refactored
> that so that Components (eg. Embedlets) cache their static values
> in instance
> variables (things like the unique ID, description, version, etc.)
> and also
> refactored how Lifecycle state was get/set in a similar manner.
>

I hate... no I actually love, to harp on this. This is the issue that we
went round and round on not so long ago. As I pointed out:

1. Performance will suffer due to the variable lookup being in-line with
mission critical code.
2. Programmers will be reluctant to make every variable access an indirect
call to a context object.
3. The context Hastable becomes a thread contention item that has to be
synchronized, bottle-necking multithreaded access (I did not point this out
but it is a fact).

Reversing the roles so that the Context is only there to provide
initialization properties and to transform/transport Embedlet properties
only when needed, is the way to go, IMNSHO.

I am very impressed with the xRAD development process that you are
demonstrating. Within a  couple of days, a critical issue was surfaced,
diagnosed, addressed and fixed!

My hat off to you!


> Here were the results, comparing async and sync event propagation
> (all values
> in events/second)  before and after the refactorings:
>
> PLATFORM        ASYNC      SYNC (Recycled)   SYNC (Non-Recycled)
>
> TINI (before):            8                 13
>       143
> TINI (after):             12                 71
>        133
>
> As you can see, the Async speed improved by 50%.  The Sync speed using
> recycled event instances (so only one is ever created) was
> markedly improved
> by the refactoring. The Sync (Non-recycled) slowed down a trifle
> due to some
> other refactoring that I put in place to improve the Embedlet
> spec interfaces
> a bit, but the net loss in speed was only about 7% (and those structural
> refactorings were necessary).
>
> I figure the SYNC (Non-Recycled) is running about as fast as the
> poor TINI
> can go, and though there might be some minor tweaking that could possibly
> help a bit, that's about all she wrote.  With the new
> refactorings, the SYNC
> (Recycled) path is probably approaching optimum as well.
>
> However, the Async is still quite disappointing.  Sure it's using
> threads and
> thread context switches, but I think it should be a bit closer to
> the  SYNC
> (Recycled) performance.  My gut feel is that this can probably be
> improved a
> fair bit by optimizing the queue structures (away from generic
> Vectors and
> Hashtables to more customized versions that are specifically tuned to the
> access patterns that async event propagation produces).  So there
> is still
> lots of room there I think.
>
>
>
>
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView,
> The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on
> major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>