About '-fwasm-exceptions' to improve performance

[frank-pian]

"-fexceptions" causes significant performance degradation. When I disabled exceptions, the efficiency of testing 'ReadStep' improved significantly and was close to that of native C++.
However, the following discussion disabling exceptions is not recommended and can lead to logic errors.
Exception "Geom_BSplineSurface: Weights values too small" when reading STEP file
So I tried the '-fwasm-exceptions' compilation parameter as recommended. This resulted in a large number of errors leading to compilation crashes.

fatal error: error in backend: In function _ZNK38GeomLib_CheckCurveOnSurface_TargetFunc5ValueEdRd: When using Wasm EH with Emscripten SjLj, there is a restriction that `setjmp` function call and exception cannot be used within the same function:
  %11 = invoke noundef ptr @_ZN21Standard_ErrorHandlerC1Ev(ptr noundef nonnull align 4 dereferenceable(176) %7)
          to label %12 unwind label %109

There are cases in OCCT code where setjmp and exception are used at the same time, so should we try to remove setjmp function?

[donalffons]

Yes, the performance degradation and file size impact is currently massive (as I mentioned in the thread over at the OpenCascade forums) when using non-native exceptions. Using native wasm exceptions, the performance & size impact of enabling exceptions is significantly lower. My opinion is to not enable native exception support in OpenCascade.js until there is stable support in current versions of Chromium, Firefox and Safari. Firefox was lacking support until very recently.

If you want to enable native wasm support using -fwasm-exceptions, you would have to re-build the entire Docker image using this flag, since native wasm support has to be enabled at compile time (and then use that docker image for linking in the docker - run phase). The docker run - phase performs mainly linking using the pre-compiled OpenCascade assets (see this diagram). You would probably have to search-and-replace the code for occurences of -fexceptions and replace those with -fwasm-exceptions. Be prepared for extremely long build times when building the Docker image, though.

However, it seems like the situation has changed. MDN says that Firefox now has "Preview browser support" for that feature, so I think it shouldn't be long until we can make the switch in OpenCascade.js.

Depending on the application you're building, you might not need exception support. My opinion is that if you don't need exception support, you should (at least try to) disable it in your production application as this greatly improves size & performance, regardless of whether native or non-native exceptions are used. Exception support is only needed (I believe) if

• you're using OpenCascade code that both throws and catches exceptions, or
• if you need to inspect thrown exceptions in JS

[donalffons]

I made some performance benchmarks a while ago with native exceptions using Chrome in this thread. This might give you an idea about the file size difference between native and non-native exception support. The "Aw, Snap!" errors I had seem to be resolved now (just tested it in Chrome 101.0.4951.54). So that's pretty great news.

[frank-pian]

I tried to replace all the '-fexceptions'. The following error occurred while building the Docker Image.

DISABLE_EXCEPTION_THROWING was set (probably from -fno-exceptions) but is not compatible with enabling exception catching (DISABLE_EXCEPTION_CATCHING=0). If you don't want exceptions, set DISABLE_EXCEPTION_CATCHING to 1; if you do want exceptions, don't link with -fno-exceptions

But I didn't find DISABLE_EXCEPTION_THROWING.

[donalffons]

That error message (from Emscripten) is weird and seems misleading. Removing -sDISABLE_EXCEPTION_CATCHING=0 from the code seems to fix this. I made a branch with native exception support and am running a build right now, which will publish an image to Dockerhub. Will post an update here, once it has gone through.

[donalffons]

There is now a single-threaded Docker image with support for native wasm exceptions under the tag donalffons/opencascade.js:staging-native-wasm-exceptions.

But I haven't yet managed to actually catch and extract any information from an exception. In this test, the exception is of type WebAssembly.Exception - as opposed to a number in the non-native case... So, currently that test fails...

[donalffons]

I started this thread over at Emscripten, asking on to extract information from a native wasm-exception.

[frank-pian]

I want to start with the official Opencascade cmake build. Do you have any experience in this field ?
I built the method according to the official cmake and replaced '-fexceptions', but something went wrong.
https://github.com/frank-pian/occt_wasm_exception_test/blob/main/Dockerfile
Thanks a million !

[donalffons]

I haven't looked at your Dockerfile in detail...
Version 1.1.1 of OpenCascade.js was using OCCT's cmake build system also. Maybe it helps to take a look at this cmake command or this emcc command?!

[frank-pian]

That seems to help a lot. I didn't find 'OCC_CONVERT_SIGNALS' in your project build parameters. So it is possible not to use setjump function.
Thank you again for.