Why all function is block JS thread?

[NiuGuohui]

Why not return Promise to run asynchronously on other threads?

[cmpayc]

Hey @NiuGuohui !

Thank you for this great question.

Yes, you are right. The code of this library is completely synchronous, uses JSI and therefore runs on the JavaScript thread. This is one of the reasons why it runs so fast. But it can also be the cause of freezing when working with large files (or working with many files in a row).

I agree that it would be nice to write an asynchronous mechanism in addition to this, so that it would be possible to perform long read/write operations in a separate thread. But this requires either adding additional async methods to the existing methods, or reworking the architecture. I am still thinking about it. Simply returning a Promise doesn't run execution on another thread - the code will run as soon as its turn in the asynchronous stack (event loop) comes up and will run in the same JS thread.
By the way, the creator of the react-native-mmkv library also encountered this problem (in his case it's even more difficult, since an MMKV instance is used): mrousavy/react-native-mmkv#446

And I want to give some measurements and tests to understand the situation (iOS, iPhone 12 Pro):

Testing on large files. We want to write 100MB to a file.

react-native-fs:

await RNFS.writeFile(
  `${RNFS.DocumentDirectoryPath}/onehundredmegabytestext.txt`,
  oneHundredMegabytesText,
);

It will take 57662ms (57s). Since the bridge runs native code on the main thread (UI thread), the entire UI will be blocked for 57s.

react-native-fs-turbo:

RNFSTurbo.writeFile(
  `${RNFSTurbo.DocumentDirectoryPath}/onehundredmegabytestext.txt`,
  oneHundredMegabytesText,
);

It will take 357ms (0.3s). In this case, the JS thread will be blocked for 357ms.

In case of react-native-fs, other JS code will be able to execute, but no actions with the UI will be available (swipes, etc.). In the second case, the JS code will be blocked, but some actions with the UI will be available. Both options are bad, but in the case of react-native-fs-turbo it will finish 130 times faster.

These statistics are also relevant for reading large files.

Testing on a large number of small files. We want to write 1Kb to a file 10000 times sequentially.

If we start writing in a simple loop, it will also block the UI thread and we won't be able to interact with it. Therefore, we'll go the other way (after all, our goal is to leave the ability to interact with UI), and we'll start the writing through a recursive function.

react-native-fs:

let i = 0;
const runTest = async () => {
  if (i === 10000) {
    return;
  }
  await RNFS.writeFile(
    `${RNFS.DocumentDirectoryPath}/onekilobytetext.txt`,
    oneKilobyteText,
  );
  i += 1;
  await runTest();
};
runTest();

If we run each write operation in an asynchronous function, it will take 12980ms (13s) and during this time the UI thread will be free between writing and we can perform actions with the UI. A small note - I didn't bother to figure out what this was connected with, but in this case, writing works rather choppily (with periodic stops of one second).

react-native-ts-turbo:
We won't be able to run the same code with react-native-fs-turbo, because the operations are synchronous and we'll get the "Maximum call stack size exceeded" error after ~350 iterations.
We can wrap RFNSTurbo.writeFile in a promise and run it with await Promise. But even in this case, the time between asynchronous operations will be so small that it won't be possible to interact with UI.
We can go further and wrap RFNSTurbo.writeFile in a promise and setTimeout(fn, 0) (or requestAnimationFrame).

let i = 0;
const runTest = async () => {
  if (i === 10000) {
    return;
  }
  await new Promise(resolve => {
    setTimeout(() => {
      RNFSTurbo.writeFile(
        `${RNFSTurbo.DocumentDirectoryPath}/onekilobytetext.txt`,
        oneKilobyteText,
      );
      resolve(true);
    }, 0);
  });

  i += 1;
  await runTest();
};
runTest();

In this case, we will be able to interact with UI, but the code execution time will be catastrophic - 167470ms or 167s.

And here we need to find a compromise. We can launch an await Promise with setTimeout(fn, 0) every 300th iteration, and in other cases launch a synchronous RNFSTurbo.writeFile.

let i = 0;
const runTest = async () => {
  if (i === 10000) {
    return;
  }
  if (i % 300 === 0) {
    await new Promise(resolve => {
      setTimeout(() => {
        RNFSTurbo.writeFile(
          `${RNFSTurbo.DocumentDirectoryPath}/onekilobytetext.txt`,
          oneKilobyteText,
        );
        resolve(true);
      }, 0);
    });
  } else {
    RNFSTurbo.writeFile(
      `${RNFSTurbo.DocumentDirectoryPath}/onekilobytetext.txt`,
      oneKilobyteText,
    );
  }

  i += 1;
  await runTest();
};
runTest();

In this case, the code execution time will be 1342ms (1.3s) and UI thread will be free between writing and we can perform actions with the UI.

To sum up, to work with react-native-fs-turbo in some cases (working with many files, when UI should remain active or just need to make the execution asynchronous) you need to write asynchronous handlers on top of the library yourself. In other cases, the execution time of synchronous operations is measured in milliseconds and you won't notice it.
As for working with large files - this library can handles them ~100 times faster than react-native-fs, but UI will be blocked in both cases (react-native-fs and react-native-fs-turbo).

I hope this cleared things up a bit.

[NiuGuohui]

Thank you for your narrative. In my opinion, placing all file operations into a thread pool and using callback/Promise theoretically solves the aforementioned issues. This approach is also faster compared to react-native-fs because react-native-fs performs file operations at the platform level.

Of course, you could also delegate thread-blocking issues to the user, for example, using react-native-worklet-core, but this library might be too cumbersome.