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
>