697458 - Investigate possible JavaScript slowness in Google MapsGL StreetView

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

Trying to figure why Google MapsGL, especially the new JS+WebGL-based StreetView, is slow.

In a build with the patch from bug 697450 applied, I get this profile:

    11.64% perf-13012.map             [.] 0x7f160d71e9d8  
    10.98% libnvidia-glcore.so.275.28 [.] 0x12e8423       
     7.31% libGL.so.275.28            [.] 0x9c313         
     1.91% libxul.so                  [.] js::Interpret(JSContext*, js::StackFrame*, js::InterpMode)
     1.54% libxul.so                  [.] Atomize(JSContext*, unsigned short const**, unsigned long, js::InternBehavior, OwnCharsBehavior)
     1.29% libxul.so                  [.] js::PropertyTable::search(long, bool)
     0.91% libxul.so                  [.] js::types::TypeMonitorResult(JSContext*, JSScript*, unsigned char*, JS::Value const&)
     0.90% [cryptd]                   [.] 0x5e5ab106      
     0.73% [vdso]                     [.] 0x7fffa15497b8  
     0.71% libxul.so                  [.] NameOp(js::VMFrame&, JSObject*, bool)
     0.70% libc-2.13.so               [.] __memcpy_ssse3_back
     0.64% libpthread-2.13.so         [.] pthread_mutex_lock
     0.62% firefox                    [.] arena_malloc
     0.54% libpthread-2.13.so         [.] pthread_self
     0.53% libpthread-2.13.so         [.] __pthread_mutex_unlock_usercnt
     0.51% libxul.so                  [.] mozilla::WebGLContext::ConvertImage(unsigned long, unsigned long, unsigned long, unsigned long, unsigned char const*, unsigned char*, int, bool, int, bool, unsigned long)
     0.50% gl9m4IT2 (deleted)         [.] 0x1e69          
     0.49% libxul.so                  [.] SearchTable(PLDHashTable*, void const*, unsigned int, PLDHashOperator)
     0.48% libxul.so                  [.] jpeg_idct_islow
     0.46% [kernel.kallsyms]          [k] do_raw_spin_lock
     0.46% firefox                    [.] arena_dalloc
     0.45% [kernel.kallsyms]          [k] sys_sched_yield
     0.44% libxul.so                  [.] js::mjit::stubs::GetElem(js::VMFrame&)
     0.43% [kernel.kallsyms]          [k] system_call_after_swapgs
     0.43% firefox                    [.] realloc
     0.42% libxul.so                  [.] ycc_rgb_convert_argb
     0.41% libxul.so                  [.] js_GetProperty(JSContext*, JSObject*, JSObject*, long, JS::Value*)


Does that suggest that something could be done at the level of the JS engine to make it faster?

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

Notes about that profile:

pthread_mutex_lock is primarily called by malloc, and my profile shows some JS-related stuff among the main callers there:
    _ZN2js6VectorIN3JSC22AbstractMacroAssemblerINS1_12X86AssemblerEE4JumpELm0ENS_15TempAllocPolicyEE13growStorageByEm.constprop.570
JSObject::allocSlots
JSRope::flatten
js::ArgumentsObject::create
_ZN2js6VectorINS_5types13TypeNewScript11InitializerELm0ENS_15TempAllocPolicyEE13growStorageByEm.constprop.350

Comment 2

[emeraldsnorlax]

Still happening -- panning and streetview works fine in Chromium (smooth 60fps), but in Firefox it is very choppy, especially in streetview.

Here's a profile: https://share.firefox.dev/3ist0lN

Comment 3

[emeraldsnorlax]

(In reply to emeraldsnorlax from comment #2)

Still happening -- panning and streetview works fine in Chromium (smooth 60fps), but in Firefox it is very choppy, especially in streetview.

Here's a profile: https://share.firefox.dev/3ist0lN

This seems to be solved on Google Maps by setting webgl.force-enabled to true -- what's strange is that WebGL seems to already behave correctly on other sites (e.g. the WebGL aquarium benchmark runs fine)