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".