Skip to content
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

100% cpu with 177.3 MiB zip #226

Closed
thisconnect opened this issue Jul 7, 2019 · 3 comments · Fixed by #227
Closed

100% cpu with 177.3 MiB zip #226

thisconnect opened this issue Jul 7, 2019 · 3 comments · Fixed by #227

Comments

@thisconnect
Copy link

thisconnect commented Jul 7, 2019

I accidentally passed a bigger buffer to fileType,
i.e. this file https://imagemagick.org/download/windows/releases/ImageMagick-6.9.10-33.zip

Seems to hang iterating through the whole buffer here:

zipHeaderIndex = findNextZipHeaderIndex(buffer, offset);

Is that expected?

It doesn't hang of corse if I pass just a subarray
filetype(body.subarray(0, filetype.minimumBytes)) then everything works and { ext: 'zip', mime: 'application/zip' } is returned

@sindresorhus
Copy link
Owner

// @jacor84

@thisconnect
Copy link
Author

I am currently only passing a subarray length of minimumBytes, but wonder if there would be any benefit if I pass more than that, especially with application/zip data

@jacor84
Copy link
Contributor

jacor84 commented Jul 9, 2019

I agree that this algorithm could be optimized for larger files. Expecially the findNextZipHeaderIndex function, which is using Array.findIndex(function). I will try to find a good solution and test for performance during the next few days. One idea is to use Buffer. indexOf() since we are looking for consecutive bytes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants