Sometimes it isn´t practicable to use multithreading. At least with the Softimage plugin.
At first, you must read 5 things.
First vertices, second normals, third sometimes texture coordinates, fourth faces(which polygon use which vertex-, normal-, texture-, and fiveth material-indices).
For that, you should have a geometry accessor and you should have a referenz for each mesh.
Possible is, that you can use 4 threads to read the mesh data. One for vertices, one for nomals, one for texture if present and one for the indices...
With 4 threads, you must call the accessor 4 times. That cost time.
You must store the geometry data from each thread, because the order of writing the file is imporatant, that cost memory.
You must wait if each thread is finished, because the order of writing, cost time.
All that and the fact that 4 threads aren´t 4times faster, because the thread handling, gives me the not needed argument.
And there are still other things. For example that the indices thread will use 2/4 - 3/4 of all the time.
Or i must read data double for the indices to become the vertex and normal count.
And the greatest argument is, that not the access of the data cost the most time, rather the conversation from the data to a writable string.
If you can solve that, you can half the export time. They should be faster then the import time in Octane...
You see, sometimes it isn´t practicable to convert a serial workflow, read data/write data, to a parallel one, read data/store date/wait for others/write data...