Obviously the object rowMode has the additional cost of extracting the names of the columns, but I would expect this to be computed more efficiently, maybe just once?

My assumption is that you're talking about calculating/converting (from native to JS) the column names only a single time, rather than performing the conversion on each row.

As a workaround, you can use a combination of the rowMode:'array' and columnNames:[] options to exec(), which will cause it to return the result rows as arrays but also include the column names (computed a single time), in their proper order, in the given columnNames array. That can then be used to construct the objects out of that information when the query returns. Despite the extra level of conversion from array to object, that might (might!) be faster than converting the column names from native to JS for each row.

The current code structure, because of how generic rowMode is, cannot accommodate that with a quick fix. The callback which converts the stmt object's data into the desired rowMode type does not have enough information to do that and doesn't know whether it will be called 1 time or 1000000 times.

i will look into how that callback might be rewritten from its current one-line implementation into something which can cache and reuse the column names, but the only option which currently looks API-feasible would be an internal transformation from array to object very much like the one described above, so it might (might) not be much faster. Only experimentation will answer that.

i have your demo running locally and will report back, probably sometime in the next couple of days.

As a workaround, you can use a combination of the rowMode:'array' and columnNames:[] options to exec(),

That workaround looks like (using your demo as the basis):

    // replace with 'object' to see difference in performance
    const rowMode = 'array';
    const columnNames = [];
    const result = db.exec({
      sql: 'SELECT * FROM t;',
      rowMode, columnNames,
      returnValue: 'resultRows'
    });
    if( true && 'array'===rowMode ){ // enable/disable workaround
      for( const i in result ){
        const obj = Object.create(null);
        for( const c in columnNames ) obj[columnNames[c]] = result[i][c];
        result[i] = obj;
      }
    }

preliminary tests show it to be negligibly slower than the initial rowMode='array' case and roughly twice as fast as the rowMode='object' case.

Timings on my desktop machine:

• rowMode=array: 460ms
• rowMode=array, converted to objects as shown above: 475ms
• rowMode=object: 950ms

My recommendation is, for the time being, to use that approach to fetch the results as objects.

For other folks following along: unless you're using large data sets, the performance difference falls into the level of background noise, so the above is not a blanket recommendation for all clients.

My assumption is that you're talking about calculating/converting (from native to JS) the column names only a single time, rather than performing the conversion on each row.

Yes.

As a workaround, you can use a combination of the rowMode:'array' and columnNames:[] options to exec()

This is actually a very good solution. It seems that id adds just a few milliseconds, including the construction of the objects from the column names and rows (we are around 155-60ms, compared to 300ms of rowMode: object, and 150 of rowMode: array). We'll use this for now.

Thanks a lot again!

i have your demo running locally and will report back, probably sometime in the next couple of days.

This wasn't quite as invasive as it initially appeared. It is now in the trunk but, because it's not a bug fix (per se), won't be back-ported to the 3.45 branch.

The pre-release snapshot has been updated. In order to get it to run with your demo i had to copy over all of the JS/WASM files, including sqlite3.wasm, because the Emscripten-provided symbols differ between your 3.44 build and what Emscripten built today.

Thank you for the feedback and the easy-to-test reproduction case.