Re: Shipping Headless Firefox on Linux

On 06/16/2017 10:31 AM, Dan Mosedale wrote: 2017-06-16 6:22 GMT-07:00 Ehsan Akhgari >: On 06/15/2017 04:37 PM, Nathan Froyd wrote: Would it be feasible to use headless mode for mochitests (or reftests, etc.

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

On 6/16/17 7:22 AM, Henri Sivonen wrote: My hypothesis is that the JSC/WebKit overhead of returning a string from C++ to JS is much lower than SpiderMonkey/Gecko overhead or the V8/Blink overhead. It definitely is. JSC and WebKit use the same exact refcounted strings, last I checked, so

Re: How are events passed between chrome and content?

On 6/16/17 6:18 AM, smaug wrote: > On 06/16/2017 02:32 AM, Jim Porter wrote: >> Here's the code I'm currently using to generate a contextmenu event: >> . >> > That just dispatches the event to dom.

The Joy of Profiling

(cross-posted between dev-platform and firefox-dev - please send responses to the dev-platform list). TL;DR: New show on AirMo - Joy of Profiling, examining Profiles: https://air.mozilla.org/search/?q=the+joy+of+profiling . Want your profile up on the show? Submit it via

Performance-related preferences

Hello developers, A couple months ago, Andreas Bovens and I scoured AMO and the Web looking for extensions and articles that offered preferences tweaks in the name of performance. Our hope was to put some of these tweaks through user testing to see if they made any difference in Firefox

Re: Shipping Headless Firefox on Linux

Supporting a "--headless" flag for the web platform tests would be great. I think we should keep running all the tests in a real environment but try to get all of them running in headless as well. Most of the failures will be fixed by some work I did in the windows support bug[1]. I'll look into

Re: BaseThreadInitThunk potential collateral benefits

I'm so happy for this hammer to slam down. Goodbye, at least a good bit of horrible DLL injections and crashes, and horrible BaseThreadInitThunk. Thanks for the explanation. The suggestions for next actions sound good too. - Liz On Mon, Jun 5, 2017 at 2:36 PM, David Durst

Re: Shipping Headless Firefox on Linux

Dan and Andreas bring up points that I was going to add, but to further it a bit more: Running tests in the correct real environment is important and I think we'd have to be very cautious of running tests in headless mode only. I see headless more as a complimentary testing mode, where you have

Re: Shipping Headless Firefox on Linux

2017-06-16 6:22 GMT-07:00 Ehsan Akhgari : > On 06/15/2017 04:37 PM, Nathan Froyd wrote: > >> Would it be feasible to use headless mode for mochitests (or reftests, >> etc. etc.)? >> > Running the tests that we rely on for correctness on an environment that > looks this

Re: Shipping Headless Firefox on Linux

Also sprach Dan Mosedale: 2017-06-16 6:22 GMT-07:00 Ehsan Akhgari : On 06/15/2017 04:37 PM, Nathan Froyd wrote: Would it be feasible to use headless mode for mochitests (or reftests, etc. etc.)? Running the tests that we rely on for correctness on an environment

Re: Shipping Headless Firefox on Linux

Also sprach Ehsan Akhgari: On 06/15/2017 04:37 PM, Nathan Froyd wrote: Would it be feasible to use headless mode for mochitests (or reftests, etc. etc.)? Running the tests that we rely on for correctness on an environment that looks this different than the environment that our users run

Re: Shipping Headless Firefox on Linux

On 06/15/2017 04:37 PM, Nathan Froyd wrote: On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote: Headless will run less of the platform specific widget code and I don't recommend using it for platform specific testing. It is targeted more at web developers and testing

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

On Fri, Jun 16, 2017 at 2:08 PM, Jan de Mooij wrote: > Objects are already nursery allocated, so that's probably why ArrayBuffer > is faster. > Sorry, I think ArrayBuffers are not nursery allocated right now, so allocating a ton of them would also trigger major GCs. Also

Re: Overhead of returning a string from C++ to JS over WebIDL bindings

I profiled this quickly and we're spending a lot of time in GC. Nursery allocating strings (bug 903519) is going to help a lot here as it will make both string allocation and GC much faster. Objects are already nursery allocated, so that's probably why ArrayBuffer is faster. We create external

Overhead of returning a string from C++ to JS over WebIDL bindings

I noticed a huge performance difference between https://hsivonen.com/test/moz/encoding_bench_web/ and https://github.com/hsivonen/encoding_bench/ . The former has the overhead of JS bindings. The latter doesn't. On a 2009 Mac Mini (Core 2 Duo), in the case of English, the overhead is over twice

Re: How are events passed between chrome and content?

On 06/16/2017 02:32 AM, Jim Porter wrote: On 6/15/17 4:12 PM, Kartikaya Gupta wrote: Not quite. For e10s, mouse events are sent across the process boundary using the PBrowser ipdl protocol. On the parent side they go into EventStateManager::DispatchCrossProcessEvent [1] which picks up the

Re: New character encoding conversion API

On Thu, Jun 15, 2017 at 3:58 PM, Nathan Froyd wrote: > Can you file a bug so `mach vendor rust` complains about vendoring > rust-encoding? Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1373554 -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/

Re: Shipping Headless Firefox on Linux

On 15/06/17 21:51, Ben Kelly wrote: On Thu, Jun 15, 2017 at 4:37 PM, Nathan Froyd wrote: On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote: Headless will run less of the platform specific widget code and I don't recommend using it for platform