stl export could also benefit from the fact that soon, jscad will generate buffers with vertex data for rendering. Those are typed arrays and transferable. My guess is that after render uploads them to GPU thes can be transfered later when export is triggered.

I could explore a bit if there would be benefit of paralelizing STL generation (due to overheads a preparation for parallelism might incur).

Also for ASCII STL, there could be difference in speed if array of strings is generated instead one huge string. It might give a speed-up, as Blob accepts array of data.

these things also all apply to the new 3mf export (3mf is zipped XML)

I had to go pretty large to get some slowdown

sphere({radius: 100, segments: 999})

that produces 499500 polygons (999000 vertices) and generated STL is 300MB

I have two jscad websites:

• regl based openjscad.xyz
• threejs based version

this should be retested after fixing #812

changing STL export to use buffer with vertices(the one created for render) instead of geom with polygons should then give same result for both engines. And the other numbers should be closer.

3mf object raw size before zip is 220MB for the same huge sphere sphere({radius: 100, segments: 999}) and after compression final 3mf file is 24MB

After testing two versions of 3mf generator, there is nice gain if string concatenation str += is replaced by pushing those strings to a big array and returning arr.join('') at the end.

• 1900 ms for str += and return str
• 1200 ms for arr.push() and return arr.join('')

also the STL ASCII generator mentioned in previous comment

• 3700 ms for str += and return str
• 2500 ms for arr.push() and return arr.join('')

One counter intuitive result is that for huge arrays preallocating the huge array makes performance worse
... 4500 ms for arr.push() and return arr.join('') if array is preallocated. Yet for binary STL export preallocating the typed array makes the export blazing fast (6500->130 ms).