OCCT 6.7.0: performance and stability


Hello All,

During preparation of OCCT 6.7.0 we have made some improvements related to performance and stability of the code which I would like to describe here.

Inspired by advice of our contributors, we have checked possibility to improve performance by tweaking relevant compiler options. The analysis was limited to Visual Studio compilers (used by most of our customers). Here is a summary chart comparing different versions of VC++ on OCCT code.

The conclusions are:

  • Enabling SSE 2 option increases performance of 32-bit code by about 6% in average. This option is now used for vc8, vc9, and vc10 compilers (it is not needed for vc11 and vc12 as they have SSE2 enabled by default, as well as 64-bit compilers).
  • 64-bit code runs 20-30% faster than 32-bit (not a piece of news, but may deserve attention of projects which have not yet moved to 64-bit!).
  • Among VS compilers, vc10 produce the fastest code.

Other compiler options tried have shown no noticeable increase of performance. Notably, for OCCT it is important to keep the floating-point model option to be /fp:precise; using /fp:fast does not improve overall performance but leads to multiple regressions. This is especially relevant for Intel compiler which (unlike VC++) sets /fp:fast as default. This time we have found some resources to address also long-pending issue of compiler warnings. Their amount has been considerably decreased, and now we have zero warnings on VC++ compilers with maximum diagnostic level (-W4). GCC, CLang, and Intel compilers still produce many warnings which shall be gradually eliminated in coming months.

These activities allowed us to spot and fix a dozen of stability issues like use of uninitialized variables. In result, some annoying problems we experienced previously during execution of tests have gone. However, a few known problems still remain, and we would appreciate help of community in their analysis and fixing. In particular, there are two known problems in handling software signals:

  • Stack overflow cannot be handled on 64-bit Windows, see issue #24255
  • Floating-point exceptions are not handled on Mac OS X, see issue #23802

Both issues can be checked with DRAW command

Draw[]> test bugs fclasses bug6143 -echo

If someone knows how to resolve these problems, please share your knowledge.


thomas paviot's picture

A workaround for floating point exceptions on OSX is to use the clang sanitizer (see http://clang.llvm.org/docs/UsersManual.html#id28). On the latest OSX 10.9 (Maverick) running clang-5.0.0 (based upon clang-3.3-svn), enabling a bunch of sanitizers gives the following result :

Draw[1]> Draw[2]> pload QAcommands
Plugin file name has not been specified. Defaults to DrawPlugin
Variable CSF_DrawPluginDefaults has not been explicitly defined. Set to /Library/OCE/0.14-dev/share/oce-0.14-dev/src/DrawResources
Parse Value ==> TKQADraw
Parse aCurKey = TKQADraw
Parse aCurKey =
aResource = QAcommands
Value ==> TKQADraw
Draw[3]> OCC6143
(Integer) Divide By Zero...
Caught (SIGILL 'illegal instruction' detected.)... KO
(Real) Divide By Zero...
Caught (SIGILL 'illegal instruction' detected.)... KO
(Integer) Overflow...
Caught (SIGILL 'illegal instruction' detected.)... KO
(Real) Overflow...
-- inf=1.7976931348623157e+308*1.7976931348623157e+308 Does not Caught... KO
(Real) Underflow
-- 0=9.9999999999999991e-309*9.9999999999999991e-309 Does not Caught... (But) Ok
(Real) Invalid Operation...
nan=sqrt(-1) Does not Caught... KO
Segmentation Fault...
Caught (SIGILL 'illegal instruction' detected.)... KO
TestExcept: failure

Don't know however if such an exception can be catched.

Hope this helps,

Andrey BETENEV's picture

Hello Thomas,

Thank you for the hint! Looks promising, we will try this.