mozilla :: #jsapi

15 May 2017
09:56efyxHi I am trying to build a simple "hello world" applications on windows with JSAPI45, but I am not able to link my program with js_static.lib
09:56efyxI am getting 6 errors similar to this one
09:57efyxjs_static.lib(Unified_cpp_js_src15.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) bool __cdecl mozilla::IsFloat32Representable(double)" (__imp_?IsFloat32Representable@mozilla@@YA_NN@Z) referenced in function "public: virtual bool __cdecl js::jit::MConstant::canProduceFloat32(void)const " (?canProduceFloat32@MConstant@jit@js@@UEBA_NXZ)
09:57efyxThese symbols seems to be defined in mozglue.lib which I link against, but no luck
09:58efyxThe link command I use is the following : link.exe -NOLOGO -OUT:test.exe test.obj build/third-party/js_static.lib build/third-party/icuin.lib build/third-party/icuuc.lib build/third-party/icudt.lib kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib psapi.lib dbghelp.lib build/third-party/libnspr4.lib build/third-party/libplds4.lib build/third-party/libplc4.lib build/third-party/mozglue.lib
11:08smaugjandem: want to quickly retest https://bugzilla.mozilla.org/show_bug.cgi?id=1347525?
11:08firebotBug 1347525 NEW, nobody@mozilla.org Setting innerHTML slower than in Chrome/Safari
11:08smaugI'm hoping we could split the Safari part to a separate bug
11:08smaugNightly vs. Chrome are now on par on Windows
11:09smaugand on Linux we're faster
11:10smaugjandem: I mean, could you test on mac
11:10jandemsmaug: sure, sec
11:14jandemsmaug: chrome is still around 40 ms, Nightly sometimes gets 41 ms but most of the time it's like 44 ms
11:14smaugjandem: on mac?
11:15jandemyes
11:15jandemsmaug: lot of progress though, close enough to call it fixed I think
11:16jandemsmaug: let's see if I still see malloc/free in the profile
11:16smaugok. And perhaps someone on Mac could still do some profiling
11:16smaugyeah, lots of malloc/free should be gone, but not all of that can be removed
11:17smaugFWIW, I've tried to find people to look at the input.value bug
11:18smaugIf nothing else, I'll focus on that one next week @Toronto
11:20jandemsmaug: awesome, would be great to have that fixed. It might also make sense to look at the original speedometer tests, I'm not sure if my micro-benchmark is very representative
11:21smaugjandem: right. Most of Speedometer is JS
11:21smaugwhen running whole tests
11:27jandemsmaug: yeah but I mean in case the input.value setter behaves differently on a page with more content
11:27jandemsmaug: so for free we have the following (after I changed the iteration count of the outer loop to 20) https://pastebin.mozilla.org/9021723
11:28smaugnot very high %
11:28jandemand zone_free_definite_size https://pastebin.mozilla.org/9021724
11:29jandemyup
11:31jandemsmaug: it's possible Clang is emitting slightly worse code for the html parser/tokenizer
11:31jandemi've noticed it's pretty conservative when it comes to inlining
11:34jandemsmaug: just curious, is the html parser something we could in theory port from Java-compiled-to-C++ to Rust at some point? or switch to the one servo uses?
11:34jandemor does it rely on too much Gecko code
11:34smaugHow would porting to Rust help?
11:35jandemI'm just curious
11:35jandembut the same compiler backend (llvm) on all platforms would be kind of nice
11:35smaughsivonen would be the right person to ask
11:36smaugbut I doubt Servo has focused on performance of the parser
11:36jandemfair enough
11:36smaugpersonally I'd like to see us dropping java-compiled-to-C++ setup
11:36smaugit is complicated
11:55tillsmaug: I get between 95ms and 100ms in Nightly, 85ms and 90ms in Chrome Canary, and an almost entirely constant 56ms in Safari
11:55smauginteresting
11:55smaugand very slow numbers
11:55tillyeah
11:55tillthis is a Fall 2012 MBP
11:55tillbut still, a lot slower
11:56smaugeven on the low end quantum flow laptop on Windows I get 59 (64bit Win 10, Chrome and Nightly)
11:56tillsmaug: also, Safari shows the result *much* quicker than the others. Looks a lot like it's faster in parts that aren't benchmarked, too
11:56tillhuh
11:56smaugon this linux machine I get 44
11:56tilllet me close all the things and try again
11:58tillhmm
11:58tillsmaug: a bit faster, but still ~80ms in Nightly
11:58tilland the same in Chrome
11:59tillno difference in Safari
12:00smaugright
12:00smaugI filed a new bug to figure out why Safari is faster
12:00tillsince this seems quite strange, I'll reboot into a clean profile and try there
12:00smaugone needs to do some Instruments profiling
12:00smaugBug 1364861
12:00firebothttps://bugzil.la/1364861 NEW, nobody@mozilla.org Setting innerHTML slower than in Safari
12:01Yoricdherman: ping
12:02tillsmaug: just to be sure, this is still with the test case from comment 0, right?
12:02smaugyeah
12:02tillok
12:14tillsmaug: no difference in timings. Perhaps this test is unusually reliant on CPU features that my laptop doesn't have? I don't really have another explanation - it's not like hardware actually got all that much faster over the last few years
12:22smaug2012 is old
12:22smaugreally old
12:24tilltrue
12:25tillsmaug: profile here https://perfht.ml/2qnem0d
12:25tilllooks largely empty
12:26smaugno it doesn't
12:27smaugneed to focus set_innerHTML
12:27smaugbug 1355441 should help a bit
12:27firebothttps://bugzil.la/1355441 NEW, wchen@mozilla.com Don't allocate HTML5StackNodes all the time from heap
12:36tillah, indeed
14:30leobaltershu: catching up on https://bugzilla.mozilla.org/show_bug.cgi?id=1364608 ... I'll write a comment there.
14:31firebotBug 1364608 NEW, nobody@mozilla.org Stash rval in AsyncIteratorClose
15:41nbpsmaug: I agree for upvoting Bug 1358476, I am hoping to have that for the JS btyecode cache.
15:41firebothttps://bugzil.la/1358476 NEW, afarre@mozilla.com Add nsThread::idleDispatch(nsIRunnable, uint32_t aTimeout)
16:07tilljandem: just fyi, I stole the latest review in bug 1362753
16:07firebothttps://bugzil.la/1362753 ASSIGNED, andrebargull@googlemail.com Array.prototype.slice and Array.prototype.splice should always take the fast path for non-Array nati
16:18sfinkwho has reviewed Opcodes.h?
16:18sfinkthat query seems to have gotten slower
16:18mrgigglessfink: jorendorff x 41, jandem x 36, shu x 20
16:18jandemtill: thanks
16:44Caspy7would this be a fair place to bring up a quantum DOM question?
16:44Caspy7I'm curious if it has any security benefits
16:45sfinkhm. Maybe #content?
16:45Caspy7thanks
17:02shujandem: jonco: ping
17:02joncoshu: hey
17:02jandempong
17:03shujandem: my room?
17:04jandemshu: ok
20:31shuleobalter: ping
21:57leobaltershu: pong
21:58shuleobalter: commented in bug
22:01leobaltersure, I just saw it. In the meanwhile I covered more cases on for await looping over an async iterator.
22:01naveedsstangl: ping
22:01sstanglnaveed: pong
22:02naveedsstangl: im in my vidyo when you are ready
22:02sstangl->
22:02* naveed assumes that means OMW
22:07leobaltershu: I wrote some tests that are expose that bug. https://github.com/tc39/test262/pull/1036, all the generated files for async generators.
22:07crowbotPR #1036: Assert iterators are consumed - and closed - in dstr patterns - https://github.com/tc39/test262/pull/1036
22:07leobalterMy plan for tomorrow in the morning is doing a new sync to SM. With everything I learned, I believe it's gonna be way faster compared to my last patch.
22:08leobalterand clean
22:08shuleobalter: cool
22:59* jimb reads comments on AutoStableStringChars, notices admonition not to use it
23:00* jimb goes to searchfox.org, finds 76 uses
23:00* jimb ignores admonition
23:00jimboh, skipped
23:00* jimb searches for uses of JS_GetLatin1StringCharsAndLength, which seems not to be deprecated, finds none
16 May 2017
No messages
   
Last message: 13 days and 14 hours ago