Reading files from bundle assets is extremely slow

[devxpy]

react-native-fetch-blob@0.10.8

test code:

import RNFetchBlob from "react-native-fetch-blob";
const { fs } = RNFetchBlob;

const t1 = performance.now();
fs.readFile(
    fs.asset("bundle-assets://" + filename),
    "ascii"
).then(data => {
    console.log(performance.now() - t1);
});

results from a Nexus 5 running a development build of the app:

All tests were run whilst a <ActivityIndicator /> was running in the foreground..

Results are in millisecond, as returned by performance.now()

size	time (ms)
9.7 MB	crash and burn
4 MB	144132.19999999274
3.2 MB	115553.40000000433
1.6 MB	59854.999999995925
781 KB	28170.59999999765
78 KB	3373.600000006263

If anyone wants the files, i am happy to provide. (some xor encrypted pdf files)

[Traviskn]

Are you sure this is a problem with the files being bundle assets, or could this actually be a problem related to the size of the file?

Reading large files into memory will always be a problem, solutions will depend a lot on your use case. I usually I avoid reading files into memory and rather have other components handle large files. (For example, when dealing with videos I use rn-fetch-blob to download the video, which happens in native code, and then I pass the path to the video off to other natively implemented libraries such as react-native-video. Same approach for files like PDFs, Images, etc.)

If your use case absolutely requires reading files into memory, readStream may work better for you as documented in the Wiki:
https://github.com/wkh237/react-native-fetch-blob/wiki/File-System-Access-API#readfilepath-encodingpromise

[milesmatthias]

I experienced a similar issue when configuring my image picker to save a photo to disk first before sending to RNFetchBlob for uploading. If I upload from memory, it's fast. If from disk, it's super slow.

[esprehn]

@Traviskn fwiw this does seems to be some kind of bug in the library. It shouldn't take several minutes to read 4MB of data into memory as the OP reports. If that was true then every app would take 10m to start. :P

This looks like there's some kind of buffering or round tripping bug in rn-fetch-blob?

[JofBigHealth]

For us in Android it takes about 10 seconds each call of .fetch and .exists. Are there any other packages anyone can recommend? This makes the app unusable for our users unfortunately.

[JofBigHealth]

Note: subsequent calls to exists complete in <100ms typically. This is also true of hash.

[shxdow]

Considering there is not yet a fix for this issue, are there any work arounds (other than using readStream(...) ? I'm stuck in a situation in which the image I have to work with must reside on the device due to requirements.