On 04/08/13 08:20, daniel.za...@samsung.com wrote:
> Hi Jeremy,
>
> On 08/02/2013 05:33 PM, Jérémy Zurcher wrote:
>> On Friday 02 August 2013  03:42, Cedric BAIL wrote :
>>> Hello,
>>>
>>> On Thu, Aug 1, 2013 at 2:03 PM, Jérémy Zurcher <jer...@asynk.ch> wrote:
>>>> what is the purpose of these hooks again,
>>> Improving our tooling. Right now there is at least a few tools that
>>> can use them :
>>> - espion, that does trace every call to elementary and efl to rebuild
>>> a fake application without the application logic. Very useful for
>>> extracting only the EFL part of an application during debugging. That
>>> should make life easier for people that report bugs in there
>>> application and we don't have the mean to build them due to
>>> dependencies or something else.
> This tool is important to me, cause I want to integrate it into our GUI
> Builder in order to import existing apps .
>>>
>>> - a performance tracer that will be able to tell where we loose time
>>> and how we spend our time from event input to the next frame on
>>> screen. Could also be linked with allocation statistic like memprof.
>>>
>>> - clouseau could use them to do live update of its tree.
>>>
>>> This is just a few set of idea, I am sure that people can come with
>>> other use of it. Maybe there is also use for them by an IDE. Right now
>>> those tool where using LD_PRELOAD on eo_do with some introspection
>>> information.
>> allllright
>>
>>>> these where my numbers         before            and now
>>>>
>>>> simple inc() - 99999 calls
>>>> calls/eo_do()  EO [ns]/call  - EO2 [ns]/call  -  EO2 [ns]/call
>>>> #1              20               25                29
>>>> #3              11               15                17
>>>> #5               9               13                15
>>>> #7               9               12                14
>>>>
>>>> overriden inc - 99999 calls
>>>> calls/eo_do()  EO [ns]/call  - EO2 [ns]/call  - EO2 [ns/call
>>>> #1              46               50                55
>>>> #3              38               37                42
>>>> #5              37               36                39
>>>> #7              36               34                38
>>> Yes, I saw the slow down. I am wondering if we need the
>>> eo2_hook_*do_{pre,post}. I think we could continue to have that
>>> feature by using LD_PRELOAD on eo2_*do_{start,end}. That should lower
>>> the unitary cost of eo_do.
>> maybe better to have the tools, but not let them impact when not needed,
>> LD_PRELOAD is good for that
> I prefer too LD_PRELOAD but we need to intercept all the Eo functions
> and extract the parameters. We need all the params given to Eo and walk
> on them like Eo does, i.e determine the opId and the parameters (a
> database helps us for that).
> Since eo2_do is a macro and eo2_do_start is useless (no va_arg), we have
> for the moment no way except via hooks per Eo function.

You don't have that anymore, and will never have it again. Sorry. :) 
There are ways to achieve the same results, don't get too fixated about it.

--
Tom.



------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to