I'm noticing a bit of a trend of what I might call "endless fiddling towards
perceived perfection". This fiddling is adding cost/overhead, making things
slower and adding bugs. I do not intend to point fingers here so do NOT take
this as "this person is at fault" or personally as the issue is more one of a
trend and almost everyone seems to be on the bandwagon.
For example, the changes from file_set that take a file + group now set them
separately as 2 keys. Like now edje_file_set() does:
efl_file_unload() <- this breaks things btw and adds a bug
efl_file_simple_load()
efl_file_set()
efl_file_key_set()
efl_file_load()
This has gone from 1 eo call that it was a while ago to a file_set to 5 of them
now as it has to get the values via eo API etc. and added breaks in behavior.
That's 5x the EO call cost added there to the same functionality. I probably
have missed some more calls I'd find if I dig enough.
Eo API is expensive. It adds a safety layer and call abstraction that isn't
free. There has been a lot of work to try and shave down its cost and it's
unlikely to get staggeringly faster any time soon, if ever. Certainly not
unless major effort is put to profiling it and making carefully crafted memory
layouts and specific architecture optimizations.
Everyone should be designing APIs to go through the EO call API as *LITTLE AS
POSSIBLE*. That means things like file_set should not have split up file and
key. More objects are also costly. Events/callbacks are not cheap either. This
means probably rolling more into a single API call, single object or single
event and doing these calls less and always considering design from THAT point
of view. This may not be perfect but it's practical and performant.
There is a limit to how much you can merge of course, but the above split of
file and key is a fairly pointless split (key can always just be NULL or some
bindings/langs can tag it as an optional argument and C can just use NULL to
indicate it isn't there). Also consider how often the API is called. The
file_set()s are called a lot during startup/setup of a window/app/object and
sub objects. It's not good to go add costs to things that have lots of calls
already going on.
I brought up the whole efl.io interface design a few weeks ago too (on my todo
list to go redo) with it also going in and out a lot and being costly.
Can we please take a few big steps back and:
1. Stop the fiddling around the edges hunting for perfect design but
forgetting performance. It's busy work too that endlessly delays a stable EO
API. If it doesn't make high impact better design, then perhaps don't do it?
2. When something is done, stop thinking about perfect API design and consider
the costs. That is life and design has to work around it. There is already a
mountain of this peppered throughout eo API and it's not good.
3. If you are going to try a whole new design then try it in isolation as an
experiment that isn't beneath existing API and so it won't break things or have
major performance impacts.
4. Can we bring these kinds of design change discussions to the mailing list?
Like splitting up file and key IMHO is a fairly big change in design that has
impacts all over like above and changes a fairly large API design premise that
has been with EFL for well over a decade.
5. Start undoing some of the damage done.
6. Looking for ways to improve EO API not in terms of purity but in terms of
performance?
:)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - [email protected]
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
