On Wed, Jun 22, 2016 at 6:42 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > 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
I am not to sure of this assesment. As we are going for more asynchronous behavior, we will use it a lot more. I am specifically worried about our use in the new list view which will likely be a big user of it. We may be able to reduce pressure by doing groupped binding, still not sure at all how that can be done with model intereception (Will require some time before such an optimization can land). > 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. How many object will have a life time and a cycle as short as a promise ? Not many in my opinion. We do try hard to recycle object everywhere for that reason. Sure, it is nice to optimize and bet that we can optimize it later if necessary, but still why pay the cost in the first place ? > 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 With all the complexity added in going with an eo object, let's just say, that maybe we will find a way to get performance kinda ok and maybe find some useful case where eo api does help in some way. So here is my current proposal on how we can do a promise with eo with the constraint as outlined by tom (no overriding of the reference count infrastructure). First example of the api for user : Example 1: eo_future_use(&destination, efl_file_set(obj, file, key)); eo_future_then(destination, _then, _cancel, _progress, NULL); eo_future_cancel(destination); // No barking on NULL Example 2: eo_future_use(&destination, efl_file_set(obj, file, key)); eo_ref(destination); eo_future_then(destination, _then1, _cancel1, _progress1, NULL); eo_future_then(destination, _then2, _cancel2, _progress2, NULL); eo_future_use(&chain, eo_future_chain_then(destination, _then_chain, _cancel_chain, NULL, NULL)); eo_future_use(&all, eo_future_all(destination, destination1, destination2, chain)); eo_future_then(all, _then_all, _cancel_all, _progress_all, NULL); eo_future_link(obj, all); // We need to register a proper then/cancel callback to handle linking eo object with promise eo_unref(destination); eo_future_cancel(destination); Example 3: eo_future_then(efl_file_set(obj, file, key), _then, _cancel, NULL, NULL); Example 4: eo_future_use(&destination, efl_file_set(obj, file, key)); some->where = eo_ref(destination); f = eo_future_value_get(some->where); eo_unref(some->where); On a returned promise, you can use as many time as you want eo_promise_use and eo_ref, but any other function call will trigger the fullfillment of that said promise. The trick here is in eo_future_use, which will be a wrapper on top of eo_wref_add. As eo_wref_add is an eo API that can be overriden and we can change the life cycle of the promise that way. Of course, now all promise need to actually be an Efl.Loop_User as they depend on the return on the main loop to notice that no call has been made on them and that they are unused. This means that evas will depend on ecore. On the other side the provider of a future will do : p = eo_promise_add(parent); f = eo_promise_future_get(p); eo_promise_link(obj, p); // due to restriction on future API, we can not make any call in the provider on the future, so we need a promise_link also eo_override(f, EO_OVERRIDE_OPS(replace_eo_future_cancel)); eo_promise_value_set(p, stuff, stuff_free_cb); return f; We will use Tom suggested solution by providing one object that is a promise and future at the same time, but Eo_Promise and Eo_Future type will be opaque, so we will get proper type checking in C. As their is no point on using eo callback infrastructure at all, we will just reuse the same function prototype for consistency, but won't use the callback infrastructure. This way we will have consistency and people will just have to do some cast as they do with every other events. The event structure for chained then (that return a new promise), will contain the value, the source future and the destination promise, while the the non chained one will just contain the future and the value. Since we can't make any change to the life cycle of an eo object that use eo_ref/unref/del, the rule will be that a future can't be fullfilled until all reference have been removed. This means that you should not use eo_ref/eo_unref and store a future pointer anywhere else than on the stack and temporarily. If you want to keep it around, eo_future_use is the only way. It also means that eo_del make no sense and its behavior to kill the parent will be a problem. As the future and the promise are the same object, they can only have one parent. So eo_parent_set will be disabled, except on constructor/destructor and internal use. In the same sense, eo_del will be trowing a warning and be render useless as it will be confusing to have it. This is pretty much the proposal I can sanely push on top of Eo (For a certain definition of sane). I still see no win at all into doing it (and I do see a lot of cost into doing it), but whatever I have raised my opinion and nobody really care, so... -- Cedric BAIL ------------------------------------------------------------------------------ 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
