You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have noticed, while quickly going through the codebase, that this library uses existsSync, mkdirSync, readFileSync and writeFileSync inside otherwise already async functions. Is there a reason for that?
This blocks the execution, instead of allowing Node to process along further, while the OS (filesystem) is writing/reading files.
Should we not update the code to at least use async versions from fs/promises? Optimally, I believe streams should be used, like createReadStream and createWriteStream, to minimize the impact on memory.
After a week of testing pretty much all the pdf-to-img libraries out there, this is the only one that works properly, and gives me good quality images. The only problem I now have is that it is slow.
PDF2Pic, has a nice code utilizing streams, which is extremely fast and efficient, but the owner no longer updates the library, and there are quite a few broken things, such as density, which controls the output quality. I am mentioning it here only as a potential source of inspiration.
The text was updated successfully, but these errors were encountered:
I have noticed, while quickly going through the codebase, that this library uses
existsSync
,mkdirSync
,readFileSync
andwriteFileSync
inside otherwise alreadyasync
functions. Is there a reason for that?This blocks the execution, instead of allowing Node to process along further, while the OS (filesystem) is writing/reading files.
Should we not update the code to at least use async versions from
fs/promises
? Optimally, I believe streams should be used, likecreateReadStream
andcreateWriteStream
, to minimize the impact on memory.After a week of testing pretty much all the pdf-to-img libraries out there, this is the only one that works properly, and gives me good quality images. The only problem I now have is that it is slow.
PDF2Pic, has a nice code utilizing streams, which is extremely fast and efficient, but the owner no longer updates the library, and there are quite a few broken things, such as
density
, which controls the output quality. I am mentioning it here only as a potential source of inspiration.The text was updated successfully, but these errors were encountered: