multiple workers

[hrgdavor]

I was wondering how many workers can a browser use, and when the number of users stops being beneficial
This test will calculate 22048M mod 97777
Benchmark Group #5 average: 517 ms, 16 Workers [8%]
Benchmark Group #4 average: 907 ms, 8 Workers [14%]
Benchmark Group #3 average: 1754 ms, 4 Workers [26%]
Benchmark Group #2 average: 3413 ms, 2 Workers [51%]
Benchmark Group #1 average: 6644 ms, 1 Worker [Standart Test, 100%]
http://pmav.eu/stuff/javascript-webworkers/

My laptop is a beastly gaming machine, so it actually got better all the way up to 16 threads (it has 16 logical cores)

bragging aside, this means web workers can be actually used for doing stuff faster, if the problem can be split to benefit from multi threading

I have no concrete idea how to use it yet, but I think it is a nice thing to be aware of.

[z3dev]

Actually, one of the improvements would be to do the IO conversions in a separate worker thread.

Current, the conversion from STL to source code happens within the generation thread, and therefore the source cannot be viewed in the editor. This conversation should be completed first, and results given to the editor as well as the generation thread.

Not sure about the conversion from geometry to STL (blob) but this might allow two things to happen

• allow the GUI to continue to function
• Allow LARGER geometry to be converted

[hrgdavor]

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)

[hrgdavor]

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

-	regl based	threejs based
generate model	500ms	500ms
prepare data for renderer	3800ms	250ms
first render	14000ms	990ms
time to see model after open	17 s	1.5 s
generate STL ASCII	9200ms	3700ms
generate STL binary	6500ms	130ms

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.

[hrgdavor]

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