Parsing of an STL ASCII file could be much faster

When I tried to load an STL ASCII file with STLLoader the first time I wondered why the parsing took such a veeeeery long time.

The reason is quite obvious:

Because of FileLoader’s response type being set in line 48 of STLLoader.js FileLoader loads the file into an ArrayBuffer, even if it is ASCII, so that it has to be reconverted into text by STLLoader’s ensureString function.

On my machine this reconverting takes about 12 additional seconds on Chrome and about 6 seconds on Firefox for a 40MB file.

If I have such an ASCII file and remove setResponseType('arraybuffer') on trial, the file is parsed directly and relatively quickly (about 2-3 seconds).

Author: Fantashit

4 thoughts on “Parsing of an STL ASCII file could be much faster

  1. @takahirox

    … and see how the performance with your 40MB file will be?

    The result is excellent! – Adding

    if ( window.TextDecoder !== undefined ) {
    
        return new TextDecoder().decode( array_buffer );
    
    }
    

    improves the time needed on my system for executing the ensureString function

    • on Chrome from 12 seconds before to 0.12 seconds afterwards
    • on FF from 5-6 seconds before to 0.17 seconds afterwards

    (with the previously tested 40MB STL ASCII file, on Windows 10)

    – and in spite of this the model looks exactly like before 😉

  2. Do you folks think we need loader.setResponseType() or something for
    browsers which don’t support TextDecoder?

    Getting specific, that’s IE 11 and Microsoft Edge[1]. I’d encourage interested persons to upvote the issue here. It is marked as “under consideration” currently.

    My preference would be to not add setResponseType() if it’s purely an optimization for one vendor. Setting a “text” response type for a binary .glb will not work, so it seems likely to confuse people in addition to adding code paths we must maintain.

    • [1] Excluding Opera Mini, which doesn’t support WebGL anyway.

Comments are closed.