-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Opening full file is slow and useless #27
Comments
That really matters for big images. 👍 |
Yes I think this is important when you are processing more than one image. |
@maxired : you have to be careful about testing performance with a cold cache, because your numbers will be polluted by the time needed for node to bootstrap itself:
|
@maxired btw, I implemented a different solution, instead of only reading the exact amount of needed data, I load data by chunk up until the JPEG APP1 Exif segment is fully available. This has the advantage to minimize the amount of round-trip to the kernel, whereas your solution implies a lot of them. It turns out that the time to read large JPEG is pretty minimal. As a reference, I am using a 24MB post-photoshop JPEG which came out of the new 50Mpix Canon 5DS, here is some stats (all number are in
The suffix indicate the chunk size. The following command was used to generate the numbers:
The test machine itself is running an old i3-2377M. |
@maxired exactly, such approach causes huge memory consumption ending with OOM kill, while trying to do batch processing. if you are still interested in lighter approach, take a look at this module |
Hi,
when we give a filename to the library, it use fs.readfile to open the file.
Looks like the whole file is open, which is slow for big pictures.
I suggest that we first open the header of the picture and then read only the bytes corresponding to the exif part.
I would love to submit a pull request for this, but since there is not unit test (issue #26), I am not sure not to break anything.
I am thinking about something like :
In my case, this lead to significant performance improvement : >*6 with pictures of around 7MB each (dont forget to drop your cache when doing this kind of performance analysis )
The text was updated successfully, but these errors were encountered: