CASE:
function x () {
SOURCES OF STANDARD OCTANE BENCH. GOES HERE
}
x();
You should see aprox 40% drop on performance on standard JSShell.
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozil
On 6/4/15 2:52 PM, Jason Hill wrote:
40 is stable like 38 ?
Not yet.
compileAndGo is default true now!
In 40 it's just gone, fwiw. There's a new thing for weird cases when
you're not running against a global scope that may or may not be
relevant to you but is handled automatically anyway
Can you post a small micro-benchmark (for the shell) that demonstrates the
problem?
On Thu, Jun 4, 2015 at 8:52 PM, Jason Hill wrote:
> 40 is stable like 38 ? compileAndGo is default true now!
>
> BTW; I found one another crazy puzzle.
>
> If I simply compile and run the JS sources its OKAY.
>
>
40 is stable like 38 ? compileAndGo is default true now!
BTW; I found one another crazy puzzle.
If I simply compile and run the JS sources its OKAY.
But; if I wrap the sources into a function and then call that function, I see a
performance drop aprox 1/2
I need to wrap the scripts. Any advi
On Thursday, 4 June 2015 22:36:28 UTC+5:30, Jason Orendorff wrote:
> One way is to change the class and make it global. This is just a matter of
> setting some flags in the JSClass. But each global object lives in an
> isolated compartment, and values must be "wrapped" when they are
> transferred
On 6/4/15 12:37 PM, Jason Hill wrote:
Found it. First it looked unimportant but when I set
setCompileAndGo(false) the perf is so bad. What could be the reason?
Turning off compileAndGo disables Ion altogether for toplevel scripts
and makes global variable access really slow in general.
Why are
One way is to change the class and make it global. This is just a matter of
setting some flags in the JSClass. But each global object lives in an
isolated compartment, and values must be "wrapped" when they are
transferred between compartments. This can be tricky to accomplish if you
have a lot of
Found it. First it looked unimportant but when I set setCompileAndGo(false) the
perf is so bad. What could be the reason ?
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/de
In SpiderMonkey 1.8.0 we used call JS_InitStandardClasses(cx, non_global_obj)
to get a copy of standard built-in objects in the non_global_object.
Later we used to pass this non_global_object inside JS_EvaluateUCScript so that
it gets treated as the "this" object and it used to have a copy of bui
One more thing. If I use js.c (js shell) as is, the perf numbers are good. So
whatever I'm missing not related to compile time settings or defines.
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists
> Could it be due to missing -O2 ?
>
> -j
Actually it's -O3 (O2 was slow and wanted to see O3. same)
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-int
On Thu, Jun 4, 2015 at 9:50 AM, Jason Hill wrote:
> '-std=gnu++0x', '-pthread', '-fvisibility=hidden',
> '-fno-stack-protector', '-fomit-frame-pointer', '-fno-common',
> '-fno-math-errno', '-fPIC',
> '-Wno-mismatched-tags', '-Wno-missing-field-initializers',
> '-Wno-unused-private-field', '-Wno-i
compile time settings (for both SM and my c file)
XP_MACOSX
DARWIN
HAVE_LOG1P=1, 'HAVE_EXPM1=1', 'HAVE_ACOSH=1', 'HAVE_ASINH=1', 'HAVE_ATANH=1',
HAVE_TRUNC=1, 'HAVE_CBRT=1', 'HAVE_WCRTOMB=1', 'HAVE_MBRTOWC=1',
VA_COPY=va_copy, 'HAVE_VA_COPY=1',
JS_HAVE_MACHINE_ENDIAN_H
JS_CODEGEN_X64
JS_PUNBOX
All the same settings. (Compile options, Evaluate, GC etc.) nothing different
comparing to JS Shell.
Result for the micro benchmark:
Embedded: 13907
JS Shell: 1176
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozill
This problem looks like version independent. Tried with 35.0 38.0 and all same.
___
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
Hm, these numbers (richards and regexp in particular) suggest both JITs are
enabled or they'd be even worse... Can you try this silly micro-benchmark
and see what numbers you get, shell vs embedding?
(function() { var t = new Date; for (var i=0; i<20; i++) {};
print(new Date - t); })();
A
On 6/4/15 7:28 AM, Jason Hill wrote:
All the ion, baseline settings are enabled.
May I ask what the code enabling them looks like on your end?
Also, which version of SpiderMonkey is this?
-Boris
___
dev-tech-js-engine-internals mailing list
dev-tech
Hi,
I'm trying to embed Spidermonkey into a basic C app. This sample app basically
reads a JS file (octane.. test) and executes. Nothing really special. All the
ion, baseline settings are enabled. compilation made with codegen 64 enabled.
Below results are from embedded app:
Richards: 9048
De
18 matches
Mail list logo
