On Mon, May 15, 2017 at 10:14:10AM -0700, Sam Foster wrote:
I think this deserves a round of applause. Its a large undertaking with
measurable perf wins in areas with strong SEP(1) fields
Do you have measurements? It seems likely to be a perf win, but
I haven't seen any metrics to confirm what
I think this deserves a round of applause. Its a large undertaking with
measurable perf wins in areas with strong SEP(1) fields
1. https://en.wikipedia.org/wiki/Somebody_else%27s_problem
/Sam
On Wed, May 10, 2017 at 7:09 PM, Florian Quèze wrote:
> On Mon, Mar 27, 2017 at 9:42 PM, Dave Townse
On Mon, Mar 27, 2017 at 9:42 PM, Dave Townsend wrote:
> lets go ahead with this and avoid using Task.jsm in the future.
Patches to remove Task.jsm usage from browser/ and toolkit/ are now
available in https://bugzilla.mozilla.org/show_bug.cgi?id=1353542
along with the scripts that generated them
On Mon, Apr 3, 2017 at 9:38 AM, Joshua Cranmer 🐧
wrote:
> On 3/16/2017 5:29 PM, Dave Townsend wrote:
>
>> For a long time now we've been writing JS code that waits for promises
>> using Task.jsm and generator functions. Recently though the JS team added
>> support for the JS standard way of doing
On 3/16/2017 5:29 PM, Dave Townsend wrote:
For a long time now we've been writing JS code that waits for promises
using Task.jsm and generator functions. Recently though the JS team added
support for the JS standard way of doing this, async/await:
https://developer.mozilla.org/en-US/docs/Web/Java
On Mon, Mar 27, 2017 at 12:42:46PM -0700, Dave Townsend wrote:
It looks like the main concern raised about switching over to async/await
where possible is bug 1242505.
I personally wouldn't consider this a blocker. I'm all for it
being fixed, but the benefit of not having Promise.jsm noise in
It looks like the main concern raised about switching over to async/await
where possible is bug 1242505. We're going to try to get some resources for
fixing that bug and it probably blocks doing a mass rewrite of existing
code but I don't think it blocks people starting to use async/await right
now
On Sun, Mar 26, 2017 at 8:16 PM, Ehsan Akhgari
wrote:
> On 2017-03-17 7:41 PM, Kris Maglione wrote:
> > On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote:
> >> Have we measured the performance of our async/await implementation? I
> >> think we should definitely do some extensive test
On 2017-03-17 7:41 PM, Kris Maglione wrote:
> On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote:
>> Have we measured the performance of our async/await implementation? I
>> think we should definitely do some extensive testing of the performance
>> of any new ES primitives before decidi
On 3/17/2017 5:19 PM, Dave Townsend wrote:
One issue I have just spotted is that Task.jsm uses a JavaScript
implementation of promises under the hood while async/await obviously uses
our native implementation in the JS engine.
You're inadvertently losing test coverage if you convert everything
On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote:
Have we measured the performance of our async/await implementation? I
think we should definitely do some extensive testing of the performance
of any new ES primitives before deciding to switch to using them in the
front-end code en m
On 2017-03-16 6:29 PM, Dave Townsend wrote:
> For a long time now we've been writing JS code that waits for promises
> using Task.jsm and generator functions. Recently though the JS team
> added support for the JS standard way of doing this, async/await:
> https://developer.mozilla.org/en-US/docs/W
On Fri, Mar 17, 2017 at 10:19:02AM -0700, Dave Townsend wrote:
One issue I have just spotted is that Task.jsm uses a JavaScript
implementation of promises under the hood while async/await obviously uses
our native implementation in the JS engine. This may mean the two have
slightly different char
One issue I have just spotted is that Task.jsm uses a JavaScript
implementation of promises under the hood while async/await obviously uses
our native implementation in the JS engine. This may mean the two have
slightly different characteristics. That shouldn't matter for new code
written but may c
On Thu, Mar 16, 2017 at 09:08:24PM -0400, Michael Layzell wrote:
Can we pass async functions everywhere where we use `add_task` in tests
already? If we can't, is there a tracking bug for converting all of the
test systems to support it?
Yes, add_task accepts any function which returns a promise
I mostly use tasks when writing tests, so I mostly have questions about how
it's use in that situation will be affected.
Can we pass async functions everywhere where we use `add_task` in tests
already? If we can't, is there a tracking bug for converting all of the
test systems to support it?
Can y
Sounds like a good change to make from the discussion so far.
If there are issues with stack traces, I would assume having more of our
code base using async / await is a good way to apply pressure for stack
trace improvements (if needed) that will benefit everyone.
- Ryan
On Thu, Mar 16, 2017 at
On Thu, Mar 16, 2017 at 05:39:06PM -0500, J. Ryan Stinnett wrote:
For modules that have already converted, is there any performance change
(good or bad) between async / await vs. Task?
I haven't noticed any differences either way, but I also haven't
done any explicit profiling. There's definit
For modules that have already converted, is there any performance change
(good or bad) between async / await vs. Task?
- Ryan
On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione
wrote:
> On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:
>
>> Writing code in standard JS is always better
On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote:
Writing code in standard JS is always better for the web, makes it easier
to onboard new engineers and allows for better support in developer tools.
So I'd like to propose that we switch to the standard way of writing these
functions
For a long time now we've been writing JS code that waits for promises
using Task.jsm and generator functions. Recently though the JS team added
support for the JS standard way of doing this, async/await:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
W
21 matches
Mail list logo
