I'm looking at the efl.io design and ... I don't like it.
(k-s - for you if you're listening).
I'm not saying it isn't clean or neat. It *IS* expensive. EO calls are costly.
We should avoid designing things that rely on making lots of them. let me give
a snippet of code:
...
efl_event_callback_add
(obj, EFL_IO_READER_EVENT_CAN_READ_CHANGED, _th_read_change, NULL);
...
static void
_th_read_change(void *data EINA_UNUSED, const Efl_Event *ev)
{
Eo *obj = ev->object;
char buf[4096];
Eina_Rw_Slice rw_slice = EINA_SLICE_ARRAY(buf);
while (efl_io_reader_can_read_get(obj))
{
Eina_Error err = efl_io_reader_read(obj, &rw_slice);
if (!err)
{
// XXX: access rw_slice with eina calls
...
My problem with this is in the _th_read_change() handling. It requires per
"unit" read (here up to 4k) we will have to do 3 eo calls. For I/O that is
smaller with lots of little messages this means a callback to _th_read_change()
which is kind of unavoidable THEN at LEAST 3 eo calls.
1. efl_io_reader_can_read_get() returns true -> data to read.
2. efl_io_reader_read() reads data
3. efl_io_reader_can_read_get() again next loop returns false.
Reality is this will be super common. For anything that cares about
performance, this will suck. At least for reads it definitely will. Layering
anything on top with more classes won't help as they all will internally have to
do the above anyway just adding to the cost anyway or at a minimum being the
same.
My take is that the IO class needs to pre-read (how much is a policy
tweak/option that can be set on the object via the IO class API) and simply
present this slice to the "read" callback. then inside the cb no eo calls are
needed to get the data. It's already there, ready to go. This would be a fairly
major change to the API, but IMHO necessary. Going with what we have right now
I think is asking for a "performance disaster" baked right into our API design
in this area.
On the write side, we have no real choice - there has to be an eo call to
submit some buffer (slice) to write. That's how it's going to be.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
