Alternative to Promise

[Andrea Giammarchi]

FWICT Promises and Generators aren't designed at all for best performance,
which is why nobody cares much on the IoT world of micro controller where
"5 objects" instead of just one callback makes practically no sense
(Espruino or Duktape just to name few).

Where there is a lot of RAM and a decently fast CPU thought, these extra
objects are AFAIK usually quickly trashed so that abstraction wins,
whenever the hosting environment doesn't care about RAM and CPU, over
extreme performance, and usually developers don't care.

> the performance might be much worse than a non-async continuation passing
API

naaaaa, events works just fine at "speed-light" like they've always done
and still non blocking, which is what brought us here today,  together with
nodejs and stuff.

You can choose to not lock you inside a Promise only pattern/system (which
I hope is not where ES will end up neither)

Anyway, I've been writing and testing (and playing with) most micro JS
capable controllers ... maybe Rick might actually tell you even more on
where these things are indeed a performance concern but I guess he'll agree
regular machines, as well as most modern phones, shouldn't have any trouble.

Just my thoughts,
  best regards.


.

On Thu, Oct 1, 2015 at 8:31 PM, Matthew Phillips <matthew at bitovi.com> wrote:

> On Thu, Oct 01, 2015 at 01:57:01PM +0800, Yad Smood wrote:
> > To be frankly, I can't read your doc in just 5min, it's a little obscure
> to
> > me. Please don't stick on performance or internal complexity, it's not
> the
> > bottleneck.
>
> Performance could be a bottle neck in some situations. I'm particularly
> worried about what the performance implications will be on the Loader
> spec with it's heavy use of promises. With that spec there will be a
> minimum of (I think?) 5 Promises created for every module, and perhaps
> many more if custom loaders are used. When you do the math that's going
> to wind up being a lot of Promises, which always have to go on a task
> queue, to a load non-trivial sized applications and the performance
> might be much worse than a non-async continuation passing API.
>
> I'd like to see this data before I conclude Promises solve all of our
> continuation needs.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151001/f895692b/attachment.html>