I also wont be there initially. I got a meeting at 4pm.
But I'll join as quickly as possible.
Grtz
On Tue, Apr 11, 2017 at 2:30 AM, Jeff Walden wrote:
> On 04/08/2017 02:04 AM, Shu-yu Guo wrote:
> > 7am is... hard. I'll try.
>
> Whoops, I misread the time in the original email when I first saw
On Thu, Apr 28, 2016 at 8:48 AM, Nicholas Nethercote wrote:
>
> - Would "extended assertions" help? By this I mean verification passes
> over complex data structures. Compilers often have these, e.g. after
> each pass you can optionally run a pass that does a thorough sanity
> check of the IR. Do
This is a heads up of the following change:
In bug 1063816 we are tracking to rename useCount to the more appriopiate name
of warmupCounter.
The purpose of this count(er) still stays the same, but the name now says
exactly what this number does. It is a warmupCounter deciding when Baseline and
Yes indeed.
On Wed, Jun 11, 2014 at 3:05 AM, Nicholas Nethercote wrote:
> On Tue, Jun 10, 2014 at 4:09 AM, wrote:
> >
> > - The about:config option javascript.options.ion.parallel_compilation
> gets renamed to javascript.options.ion.parallel_compilation
>
> I suspect the latter should be
> ja
Hey everybody,
I want to report a change to the js shell and the browser that might be good to
know. When bug 1020364 lands there will be three name changes:
- The shell option --ion-parallel-compile gets renamed to
--ion-offthread-compile
- The about:config option javascript.options.ion.parall
I think we also miss "Performance regressions".
Those also should get high priority. We should at least make sure they
don't stick too long in the tree.
The reason for this is that it could obscure other regressions or in the
worst case scenario be present on merge date.
Making it hard to track and
This is an awesome idea! Now I won't be able to attend the first few ones,
(since 7pm and other obligations).
But when I can I will come and give my honest opinion on the different
cakes.
grtz Hannes
On Tue, Apr 8, 2014 at 11:45 AM, Nicholas Nethercote wrote:
> On Tue, Apr 8, 2014 at 7:16 PM,
Awesome! Makes it even easier to spot and debug ARM bugs.
Thanks Hannes
On Wed, Jan 29, 2014 at 7:42 PM, Jan de Mooij wrote:
> I just landed an ARM simulator for JIT code, imported from V8 (bug 959597
> [0]).
>
> This means if you build an x86 shell and pass --enable-arm-simulator
> to configu
ing tip shell, or
> Firefox Nightly? Might be worth checking out Aurora. Thanks,
>
> /be
>
>
> hv1989 wrote:
>
>> So the given benchmark shows the speed is the same.
>>
>
___
dev-tech-js-engine-internals ma
- caches
- alignment
- ...
In all these cases more iterations won't help.
grtz Hannes
On Mon, Jan 20, 2014 at 9:43 PM, Brendan Eich wrote:
> hv1989 wrote:
>
>> This is really micro micro benchmarking. I mean the difference you
>> measure possibly isn't because we outpu
We indeed can and do hoist array.length if we can observe it definitely
doesn't change. In the micro-benchmark provided we definitely can:
test.js:
function test_arr_length() {
var arr =
[1,2,3,4,5,6,8,43,43,4,432,432,432,432,432,432,432,32,542543,6536,5354,5,2532,432,4546,36,345,243,4,436,5,654
; var re1 = /(((\w+):\/\/)([^\/:]*)(:(\d+))?)?([^#?]*)(\?([^#]*))?(#(.*))?/;
>
> to see how good the performance can get?
>
> Best,
>
> - Julian
>
>
> [1]:
> https://github.com/jviereck/regexp.js-octane/commit/0d6e01d36a7d5dc24c385e3437e6b740dbd9da78#diff-0
>
> [2
Hi Julian,
I'm not sure what you have tried. But I tried your hardcoded version.
(i.e. defining RegExpJS ourself, with the ^ba hack)
- octane1.0-regexp:
before: 4510
after: 4658
- octane2.0-regexp:
before: 2585
after: 2390
So in octane1.0 that is indeed an improvement. For octane2.0 not and
tha
Makes a lot of sense for me!
I agree it would be good to have a 'jit' submodule and somebody owning it. A
central person that can be addressed and keeps the submodule healthy. Jan seems
a good fit to take that role. He's one of the authors of Baseline. Helped a lot
in ionmonkey and still has kn
On Friday, July 19, 2013 7:37:28 AM UTC-7, Luke Wagner wrote:
> One thing that I think would be really informative is how much time is spent
> in C++ stubs called from the baseline/ion. They happen frequently enough
> that you probably wouldn't want them to be interleaved on the graph, but
> ma
I took the time to get tracelogging up and running again and create V2 out of
it. I think most know tracelogging already, but for those that don't:
Tracelogging traces when which scripts runs and which engine we use for it. Out
of the log information I create graphs showing when which engine is
On Thursday, May 30, 2013 3:23:50 AM UTC+2, Nicolas Pierron wrote:
> I think the recent trouble was mostly that we got multiple regressions in
> the one range of commits.
True and that is also the reason I want to re-empower people again when that
happens. People shouldn't be afraid to backout r
17 matches
Mail list logo
