On Thu, Jul 11, 2013 at 5:36 PM, Jérémy Zurcher <jer...@asynk.ch> wrote:
> On Thursday 11 July 2013 03:28, Cedric BAIL wrote :
>> On Wed, Jul 10, 2013 at 4:06 PM, Jérémy Zurcher <jer...@asynk.ch> wrote:
>> > still not fully functional,
>> >
>> > here is the concept:
>> >
>> > - enhance const Eo_Op_Description *descs; in Eo_Class_Description into:
>> >
>> > typedef struct _Eo_Op_Description
>> > {
>> > void *func; /**< The static function to call for the op.
>> > */
>> > void *api_func; /**< The EAPI function offering this op. */
>> > Eo_Op op; /**< The op. */
>> > Eo_Op_Type op_type; /**< The type of the Op. */
>> > const char *doc; /**< Explanation about the Op. */
>> > } Eo_Op_Description;
>>
>> Yeah, good idea to remove that second array.
>>
>> > - remove the following from class declaration and definition
>> > _Eo_Op_Func_Description []
>> > BASE_ID = 0;
>> > enum { OP_ID, ID_LAST };
>> > etc…
>> >
>> > - but add
>> > static Eo_Class_Id class_id;
>> >
>> > - on class elaboration:
>> > init class_id as BASE_ID was
>> > sort Eo_Op_Description by api_func, and set op (using base_op_id)
>> >
>> > - now EO_FUNC_BODY can do:
>> > static volatile Eo_Op op = NOOP;
>> > if ( op == NOOP ) op = eo2_get_op_id(class_id, Name);
>> > -> search (Name==api_func) in class_id(_Eo_Op_Description)
>> >
>> > then resolve the op given the calling object as usual
>> >
>> > - overriding does not use EO_FUNC_BODY()
>> > but overrides *func in _Eo_Op_Description -> usual _dich stuff
>> >
>> > so that's a little overhead on first call to resolve the OP
>> >
>> > Am I on the right thack ??
>>
>> Sounds like a good direction to follow. I would still like to expose
>> the klass where the op is found in the object instead of directly
>> doing eo2_call_resolve. This way we could add a hook before and after
>> the function call to do tracing. It will also make it possible for all
>> those functions to be pure const functions, this will help the
>> compiler greatly I believe. Note a pure const function doesn't modify
>> any of its parameter and the result is the same if the same data is
>> given to them. Think strlen.
> function pointer and associated class are both int the Dich_Chain (what
> does Dich Chain mean ??), for sure we don't want to do the lookup twice,
> (but if the pure fct is optimized, why not?)
The problem is with eo2_call_resolve as it does modify the content of
call and that make it not a pure function anymore in my understanding.
That's why I want to split it, so that the compiler can merge and
remove calls to eo2_call_resolve at the end. Well, in fact, I do hope
that if the compiler is smart enough it will be able to move that
evaluation outside of the loop and remove it from the hot path
completely. That should be the case in the end for all call to eo2_do
and give it an unfair advantage over eo_do.
> maybe we should expose op_type_funcs, but _Eo_Class is not public,
> sometimes anoying that strict separation, I'll figure something out now.
>
> I'm _aware_ of pure fcts, what do you think about
> static Eo_Op op = EO_NOOP;
> if ( op == EO_NOOP ) op = eo2_get_op_id(OpDescs, (void*)Name);
> vs
> op = eo2_get_op_id(OpDescs, (void*)Name);
>
> I wonder, I'll give a try all pure now!
Let's see that :-)
--
Cedric BAIL
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
