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

Hashing speed and cores #1233

Closed
Ciao121 opened this issue Nov 29, 2017 · 5 comments
Closed

Hashing speed and cores #1233

Ciao121 opened this issue Nov 29, 2017 · 5 comments

Comments

@Ciao121
Copy link

@Ciao121 Ciao121 commented Nov 29, 2017

Hi,
it seems to me that webtorrent uses a single cpu core when hashing 1 (or more) file(s)? Am I correct?
If the disk I/O it's not a problem... would using multi cores speeds up this process?

@DiegoRBaquero

This comment has been minimized.

Copy link
Member

@DiegoRBaquero DiegoRBaquero commented Nov 30, 2017

Yes, it would. Hashing pieces and files would be done faster

@Ciao121

This comment has been minimized.

Copy link
Author

@Ciao121 Ciao121 commented Dec 3, 2017

Thanks @DiegoRBaquero,
any suggestion about what to look to implement this in an electron app?
Thank you again.

@DiegoRBaquero

This comment has been minimized.

Copy link
Member

@DiegoRBaquero DiegoRBaquero commented Dec 3, 2017

You would need to reimplemented the hashing either with a different library or by using child processes

@stale

This comment has been minimized.

Copy link

@stale stale bot commented May 3, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label May 3, 2018
@feross

This comment has been minimized.

Copy link
Member

@feross feross commented May 4, 2018

Once a time, I actually measured hashing speed and concluded that it wasn't where WebTorrent was spending a majority of it's time. I agree that theoretically this could make things faster, but we'd need to test it before just assuming that it's a win.

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming. – Donald Knuth

That said, if someone wants to try something clever and send a PR here, I'll take a look at it.

@stale stale bot removed the stale label May 4, 2018
@feross feross closed this May 4, 2018
@feross feross mentioned this issue May 4, 2018
0 of 2 tasks complete
@lock lock bot locked as resolved and limited conversation to collaborators Jan 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.