0gg5UJmM

1This mail seems to cover up 2 quite unrelated things: a bug (fix), and the general discussion about efl-interfaces.
2
3The bug you have fixed in EFL is pretty much unrelated to eo or the file interface. It was added in f10a3c9ee36cd270045f7e30fd3716ef15e3106d which is not related to the work that was put into the file interface in the last release.
4
5I also have to admit here that i cannot fully agree with your reasoning for 5 instead of 1 eo call. efl_file_simple_load is not a eo call. Additionally, file_set key_set and load are executed right after each other, which makes use of the eo_id cache here, which only leaves the function pointer lookup, not the pointer lookup, which cuts off a lot of cost. The unload here is a special case which is happening here in edje itself (prior to your commit, not anymore), not every object does call that. Additionally, if you just load a simple image, you will only do something like efl_file_set and efl_file_load which leaves you with 2 operations after each other, which makes them close to only 1 operation thanks to the eo_id lookup.
6
7I also tend to agree with you that we need to be carefull with what we are doing via eo calls, and what can be combined, however, the file set API is not a good example to showcase that, as this API most of the time results in a heavy operation performed afterwards, so the cost you pay after calling that API is a lot higher than the cost calling the API itself. Comparing that for example to our writer / reader API in eo, if you often need to know if something is readable now you will all the time call the same API over and over again, just to query a time little boolean flag, which gets set by some foreign entity. For me comparing those two examples, efl.file makes a lot more sense than for example Efl.Io.Reader/Writer.
8
9Additionally, there is another cost of eo that we cannot really cut off, like the cost we are paying for moving a object. A little introduction:
10If you move a layout via efl_gfx_entity_geometry_set you will actaully call:
11(On the widget object)
12- canvas_object (geometry_set gets translated to position_set)
13- widget (position_set)
14- canvas_object again (position_set)
15In the widget layer there is another call with geometry_set on the canvas object which calls:
16- canvas_layout
17- canvas_group
18- canvas_object
19
20So in this one call we have 6 lookups where we are looking up, the real eo_id, the func-ptr, and the pd. However, the reasoning for eo as a security layer there is a little bit weak, we are in inheritance, we KNOW that the object we are calling on is valid. Additionally, we can calc the pd pointer by adding the diff between the two classes to the next inheritance step, so all the work that is currently done by eo can be basically saved at compile time. The methods for applying that to the efl tree are not there yet, that needs more work, I would also love to serve here numbers, but I had other things to do.
21
22I also have to admit that I have not seen a single interface where we said goodbye to performance for the sake of clean and nice API. So as a example, the new Grid and List widget have a common interface for doing placement, that saves us a lot of duplicated code. The interfaces are designed in a way that eo funcs are called as few as possible, so the handing over of the items etc. are only involving eo for batching (like give me now 100 items starting *there*), which means, we have 1-3 eo calls per placement of items for "managing" the items, the placement itself then of course does not get around the fact of calling geometry_set, which involves calling eo api. The setup for all this also went quite a few rounds in terms of developing it, and at any time performance was a reason for this, so I am wondering a little bit where 1) and 2) and 3) are coming from.
23
24Additionally, I would be interested in 5) I do not see damage right now, yes, you found a bug in a revision, but I guess that would happen with or without eo and with or without the interface work. The tradeoff you are making here is something I have not seen so far, there are interfaces which surely did this, but those are beta, and they are also kind of out of the view for now, as (speaking for me here) i am focusing on the new widgets here, and I have not seen that much work going into something outside of that (beside Xavi's work on improving docs just *everywhere*)
25
26All I can say about that: there is the efl: api board, where there are tickets for each class/interface, so we can at least try to keep an overview of the insane amount of classes and interfaces we have, the items there are currently something to look into, the Efl.Io things are *not* in there. And I cannot locate any class that is in the stabilized column that has problems with the purity over performance thing brough up here :)
27
28Greetings,
29   bu5hm4n
30
31On 9/5/19 2:45 PM, Carsten Haitzler (The Rasterman) wrote:
32> I'm noticing a bit of a trend of what I might call "endless fiddling towards
33> perceived perfection". This fiddling is adding cost/overhead, making things
34> slower and adding bugs. I do not intend to point fingers here so do NOT take
35> this as "this person is at fault" or personally as the issue is more one of a
36> trend and almost everyone seems to be on the bandwagon.
37> 
38> For example, the changes from file_set that take a file + group now set them
39> separately as 2 keys. Like now edje_file_set() does:
40> 
41> efl_file_unload() <- this breaks things btw and adds a bug
42> efl_file_simple_load()
43>    efl_file_set()
44>    efl_file_key_set()
45>      efl_file_load()
46> 
47> This has gone from 1 eo call that it was a while ago to a file_set to 5 of them
48> now as it has to get the values via eo API etc. and added breaks in behavior.
49> That's 5x the EO call cost added there to the same functionality. I probably
50> have missed some more calls I'd find if I dig enough.
51> 
52> Eo API is expensive. It adds a safety layer and call abstraction that isn't
53> free. There has been a lot of work to try and shave down its cost and it's
54> unlikely to get staggeringly faster any time soon, if ever. Certainly not
55> unless major effort is put to profiling it and making carefully crafted memory
56> layouts and specific architecture optimizations.
57> 
58> Everyone should be designing APIs to go through the EO call API as *LITTLE AS
59> POSSIBLE*. That means things like file_set should not have split up file and
60> key. More objects are also costly. Events/callbacks are not cheap either. This
61> means probably rolling more into a single API call, single object or single
62> event and doing these calls less and always considering design from THAT point
63> of view. This may not be perfect but it's practical and performant.
64> 
65> There is a limit to how much you can merge of course, but the above split of
66> file and key is a fairly pointless split (key can always just be NULL or some
67> bindings/langs can tag it as an optional argument and C can just use  NULL to
68> indicate it isn't there). Also consider how often the API is called. The
69> file_set()s are called a lot during startup/setup of a window/app/object and
70> sub objects. It's not good to go add costs to things that have lots of calls
71> already going on.
72> 
73> I brought up the whole efl.io interface design a few weeks ago too (on my todo
74> list to go redo) with it also going in and out a lot and being costly.
75> 
76> Can we please take a few big steps back and:
77> 
78> 1. Stop the fiddling around the edges hunting for perfect design but
79> forgetting performance. It's busy work too that endlessly delays a stable EO
80> API. If it doesn't make high impact better design, then perhaps don't do it?
81> 2. When something is done, stop thinking about perfect API design and consider
82> the costs. That is life and design has to work around it. There is already a
83> mountain of this peppered throughout eo API and it's not good.
84> 3. If you are going to try a whole new design then try it in isolation as an
85> experiment that isn't beneath existing API and so it won't break things or have
86> major performance impacts.
87> 4. Can we bring these kinds of design change discussions to the mailing list?
88> Like splitting up file and key IMHO is a fairly big change in design that has
89> impacts all over like above and changes a fairly large API design premise that
90> has been with EFL for well over a decade.
91> 5. Start undoing some of the damage done.
92> 6. Looking for ways to improve EO API not in terms of purity but in terms of
93> performance?
94> 
95> :)
96>