On Wed, 22 Jun 2016 10:38:13 -0700 Cedric BAIL <cedric.b...@free.fr> said:
> On Wed, Jun 22, 2016 at 6:46 AM, Felipe Magno de Almeida > <felipe.m.alme...@gmail.com> wrote: > > On Jun 22, 2016 9:22 AM, "Daniel Kolesa" <dan...@octaforge.org> wrote: > >> On Mon, Jun 20, 2016 at 1:04 AM, Felipe Magno de Almeida > >> <felipe.m.alme...@gmail.com> wrote: > >> > it is the _perfect_ match IMO. Probably we should ask someone > >> > that actually uses Lua about it, instead of guessing. > >> > >> I'm inclined to agree with raster here. I honestly don't see > >> coroutines being a good match here - the API is one thing, and there > >> is one other thing to consider that wasn't brought up and that is > >> performance - coroutines cannot be JITed and for async stuff we'll be > >> jumping across C-Lua border all the time over classic C API rather > >> than fast FFI stuff (it will also add a significant amount of new > >> runtime on C side, which I would rather avoid) which will abort traces > >> and hurt perf. > > > > Not using coroutines because of performance in lua doesn't seem like a good > > reason at all IMO. > > <snip> > > Just focusing here on the performance issue. If you think that > coroutine are going to be a performance issue for promise, I think > this raise two points to discuss. First how good is the JIT on short > function, because if we go with events/callbacks, we will endup with > very short snippet of code. I don't know for lua jit, but most JIT I > know about are bad with short code anyway (It will literray come from > C, execute a small amount of code and go back to C). So I don't really > see why coroutine will be any worse than events/callbacks in that > case. > > Second point, if you are concerned by performance, then why is it a > good idea to switch to an eo object at all. We are now going to pay a > way higher price for an API that will be wrapped in C to be convenient > and manually binded in all bindings. So where do people still see any > win at all into moving to an eo object ? just speaking of the eo promise performance thing - here is a summary of discussions i've had with both jpeg and tasn: 1. for the vast majority of usage promises are not common and thus not an issue 2. performance issues in creating and destroying eo objects are not unique to promises, so omptimizing to make them faster will help ALL eo objects. 3. we already have the ability to optimize with del intercepts. we could actually make a del intercept at the class level (which makes much more sense for the following)... we can cache objects. since caching will only be effective on objects that don't change a lot from their constructed state to their destructed one (promises for example do not change much). so when destruction is about to begin... cache the object somewhere, and now we need to also extend construction to allow there to be a lookup for a cached object. my point here is that we can add caching class by class easily enough and all we need is maybe 10-20 cached promise objects floating about at most and pick them from the cache each time we need one. chances are this will address pretty much all the performance issues. the only other is calling methods on a promise via eo is slower but really... how much will that really matetr given that 100's of other eo calls will happen as well at the same time to handle the result of a promise etc. etc. - it's a rounding error of difference at best in the overall performance of efl -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
