[Smtk-developers] Some timing data

[David Thompson]

Hi all,

I've finally been able to build a 32-bit SMTK linked to Cubit 14.0 and run some files through the same timer script as the OCC models. One problem is that the models that the Cubit and OCC backends can both read are in the STEP and IGES format... but Cubit always runs these files through an external conversion program (to ACIS SAT) before loading the result. So the timings include this conversion. The conversion program can be run manually, but then the benchmark is loading files of different types (native for Cubit/ACIS and STEP for OCC), making direct comparison a little dubious.

As an example, loading the Stargate.stp model in SMTKTestData takes 299s including the conversion to ACIS SAT format and 222s reading the SAT file directly. OCC 6.5 took 127s and OCC 6.8 took 155s. However, the Cubit import generated about 3e6 primitives while the OCC imports generated 2.0e6 (OCC 6.5) and 2.1e6 (OCC 6.8) primitives for the same chord and normal error criteria. The Audi model takes 238s (Cubit, including STEP->SAT conversion) and generates 3.9e6 primitives.

	David

> Hoping that things would change for the better, I built CGM and SMTK with OpenCascade 6.8 (as well as 6.5 that is in the superbuild already). Attached is a graph showing that 6.8 is often slower than 6.5 in generating surface tessellations for display. In the graph, blue points are timings from OCC6.5 and red from OCC6.8. The largest model tested was the stargate model. Both versions of OCC were compiled in release mode.
> 
> The raw data is also attached and includes timings of loads with and without tessellations being generated (in the latter case, the number of primitives and vertices reported will be 0).
> 
> 	David