6 ms·
const readFileP = (...a) => new Promise((res,rej)=>readFile(...a, (e,r)=>e?rej(e):res(r))); This is a one-line implementation and is probably way faster. I wou
by anonytrary 6y ago
const readFileP = (...a) => new Promise((res,rej)=>readFile(...a, (e,r)=>e?rej(e):res(r)));
This is a one-line implementation and is probably way faster. I would totally just use this one-liner anyway.
- SavantIdiot 6y agoDid you benchmark it? OP provided the test code. Show us the data.
- anonytrary 6y agoI did just because you asked, and mine (readFileP) is faster, barely different than the callback version. Actually it's the fastest one which makes no sense, so I think this benchmark may have quite a bit of error. Results: fs.readFileSync x 696 ops/sec ±1.96% (76 runs sampled) fs.readFile x 2,045 ops/sec ±6.43% (72 runs sampled) fs.promises.readFile x 435 ops/sec ±1.76% (78 runs sampled) util.promisify(fs.readFile) x 2,053 ops/sec ±6.58% (67 runs sampled) readFileP x 2,182 ops/sec ±4.00% (67 runs sampled) fs.promises.readFile CACHED readFile x 438 ops/sec ±1.56% (79 runs sampled) Fastest is readFileP,util.promisify(fs.readFile),fs.readFile Slowest is fs.promises.readFile,fs.promises.readFile CACHED readFile index.js: const Benchmark=require("benchmark"),fs=require("fs"),path=require("path"),chalk=require("chalk"),util=require("util"),promisifed=util.promisify(fs.readFile),bigFilepath=path.resolve(__dirname,"./big.file"),suite=new Benchmark.Suite("fs"),readFileP=(...e)=>new Promise((i,r)=>fs.readFile(...e,(e,l)=>{e?r(e):i(l)})),readFileC=fs.promises.readFile;suite.add("fs.readFileSync",e=>{fs.readFileSync(bigFilepath,"utf8"),e.resolve()},{defer:!0}).add("fs.readFile",e=>{fs.readFile(bigFilepath,(i,r)=>{e.resolve()})},{defer:!0}).add("fs.promises.readFile",e=>{fs.promises.readFile(bigFilepath).then(()=>{e.resolve()})},{defer:!0}).add("util.promisify(fs.readFile)",e=>{promisifed(bigFilepath).then(()=>{e.resolve()})},{defer:!0}).add("readFileP",e=>{readFileP(bigFilepath).then(()=>{e.resolve()})},{defer:!0}).add("fs.promises.readFile CACHED readFile",e=>{readFileC(bigFilepath).then(()=>{e.resolve()})},{defer:!0}).on("cycle",function(e){console.log(String(e.target))}).on("complete",function(){console.log("Fastest is "+chalk.green(this.filter("fastest").map("name"))),console.log("Slowest is "+chalk.red(this.filter("slowest").map("name")))}).run({defer:!0}); This little bit is my "implementation": readFileP=(...e)=>new Promise((i,r)=>fs.readFile(...e,(e,l)=>{e?r(e):i(l)})) Run: npm install --save benchmark chalk && node ./index.js
- Jarred 6y agoIf you look near the end of the line for each result, that % value is the margin of error. > readFileP x 2,182 ops/sec ±4.00% (67 runs sampled) This means readFileP took between 2,094 and 2,270 ops/second. > fs.readFile x 2,045 ops/sec ±6.43% This means fs.readFile took between 1,913 and 2,176 ops/second. So its possible it did run faster, but it's also possible it ran slower. You'd probably need to run it a lot more times to have an answer.
- anonytrary 6y agoI agree, the error in their claimed deviation isn't accurate. You would need to run many trials across many devices at different times of the day for a practical benchmark; it could be a service itself. I do think the data here is enough to know that a promise wrapper here is insignificant in the grand scheme of things. This fs.promises library must do way more under the hood.
- deleted 6y ago[deleted]