4 ms·
The article is correct that promises and async iterators are not a good idea for tight innerloops. The author just doesn't seem to realize that it is possible t
by Jare 9y ago
The article is correct that promises and async iterators are not a good idea for tight innerloops. The author just doesn't seem to realize that it is possible to read parts of a file synchronously, and thus build a sync iterator that way. fs.readSync() should do it: https://nodejs.org/api/fs.html#fs_fs_readsync_fd_buffer_offset_length_position https://nodejs.org/api/fs.html#fs_fs_readsync_fd_buffer_offs...
(I assume there are 100s of npm packages that do this already)
- abritinthebay 9y agoRight, exactly. Very well put :)
- hetman 9y agoI think you've misunderstood the author's point. He would like a fast solution that also looks as simple as the Python example. Even if you have a synchronous file read function that's doing partial file reads, you can not use it inside a synchronous loop to process the returned data because it will hold up the entire Node.js event loop until the whole file has been processed. You can use the synchronous file read function in a way that doesn't hold up the main event loop but to do that you re-introduce all the complexity the author was trying to avoid.
- Jare 9y agoBut you CAN make a loop that looks as simple as the Python example; Python just happens to provide one built in, right? The Python code holds the thread for the entire duration just like the Node one will hold the event loop. Wouldn't the Python loop cause the same problems as the node one in an evented app, say, a Twister app? (sorry my Python is a few years rusty) The ideal would be just as performant as the sync Python code, but effectively async. And his observation that async iterators by design can't do it without severe overhead for such tight inner loops is very good.