Maybe I missed something on the methodology, but I have a question regarding justification of designing a complete new tool.
The article mentions "ImageMagick is slow because it does a lot more than just extract image size". So we implemented a complete new solution.
How about: "We added to ImageMagick a new command to just extract image size". So we published a small patch to Imagemagick, and got it done much faster than creating a complete new tool. On top of that, reusing tested Imagemagick data structure would probably reduce a lot maintenance cost.
I see. So this is a "fast javascript implementation to retrieve size of {image, pdf}"
And since process is a small task with many calls, it would be costly to call an external process (imagemagik) using native code.
8 comments
[ 3.6 ms ] story [ 28.3 ms ] threadwhich has sync and async methods, supports more image types, but doesnt let you measure pdfs (which requires an external lib here).
The article mentions "ImageMagick is slow because it does a lot more than just extract image size". So we implemented a complete new solution.
How about: "We added to ImageMagick a new command to just extract image size". So we published a small patch to Imagemagick, and got it done much faster than creating a complete new tool. On top of that, reusing tested Imagemagick data structure would probably reduce a lot maintenance cost.
Maybe I did not see some subtleties ?