slowdown in asm.js between 1.38.19 and 1.38.20

17 views
Skip to first unread message

Brett Paterson

unread,
Nov 15, 2019, 1:20:57 AM11/15/19
to emscripten-discuss
Hi, im just looking to see if anyone might have an idea about an SDK version update causing a >2x slowdown in our code, it is C++ mixing/resampling/reverb audio code being output via webaudio.

# sdk-1.38.15-64bit : -Os = Size: fmod.js 2158kb and fmod.js.mem 236kb.  Speed: 3.2% on 32 stereo wavs with reverb.  
# sdk-1.38.17-64bit : -Os = Size: fmod.js 2157kb and fmod.js.mem 236kb.  Speed: 3.2% on 32 stereo wavs with reverb.  
# sdk-1.38.18-64bit : -Os = Size: fmod.js 2157kb and fmod.js.mem 236kb.  Speed: 3.2% on 32 stereo wavs with reverb.  
# sdk-1.38.19-64bit : -Os = Size: fmod.js 2138kb and fmod.js.mem 236kb.  Speed: 3.2% on 32 stereo wavs with reverb.  
# sdk-1.38.20-64bit : -Os = Size: fmod.js 2141kb and fmod.js.mem 236kb.  Speed: 7%   on 32 stereo wavs with reverb.  
# sdk-1.38.26-64bit : -Os = Size: fmod.js 2143kb and fmod.js.mem 236kb.  Speed: 7%   on 32 stereo wavs with reverb.  
# 1.38.48           : -Os = Size: fmod.js 2168kb and fmod.js.mem 235kb.  Speed: 7%   on 32 stereo wavs with reverb. 
#                     -O3 = Size: fmod.js 2405kb and fmod.js.mem 236kb.  Speed: 7%   on 32 stereo wavs with reverb. 
# lastest-fastcomp is similar the last entry here.

The release notes dont seem to give a hint to sometihng that might affect performance (we dont use split_memory or strptime).
v1.38.20: 11/20/2018
--------------------
 - Remove SPLIT_MEMORY option.
 - Move getTempRet0/setTempRet0 to be JS library functions rather than
   auto-generated by fastcomp.
 - Change `strptime()`'s handling of the "%c" to match that of `strftime()`.
   This is a breaking change for code which depends on the old definition of
   "%c".

Sam Clegg

unread,
Nov 15, 2019, 12:41:36 PM11/15/19
to emscripte...@googlegroups.com
I don't see anything obvious. Perhaps the getTempRet stuff? Are you
doing a lot passing of i64 between compiled code and JS code?

One way to debug this would be checkout binaryen locally and endit you
your `.emscripten` from the emsdk to point to your locally checkout.
You should then be able to bisect (using `git bisect` or whatever
method you prefer) to find the exact commit to emscripten that caused
your regression.
> --
> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/fe8e9b10-890a-4b33-8455-e24285d7d7cf%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages