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
As a part of cargo crev I was reviewing this crate in version 1.10.1 . All was good, but I have one idea.
It seems like on Windows this crate calls the GetLogicalProcessorInformation twice. Any reason not to start with a buffer of a fix size (eg. 64 entries)? Maybe this initial buffer could be on stack, so it wouldn't really cost anything. On most machines that would cut the number of calls to just 1.
The text was updated successfully, but these errors were encountered:
What you say sounds reasonable. I'm not too familiar with Windows programming, but I noticed the source links to an example on MSDN, and it looks like they also query once to get the size needed. Is the example naive?
More optimal approach would be to use first call with some stack array of hard-coded size.
If function fails with unsufficient memory, then it will update len to required one, in which case you could fallback to heap allocated vec.
This way in happy case the call will be only once.
As a part of
cargo crev
I was reviewing this crate in version 1.10.1 . All was good, but I have one idea.It seems like on Windows this crate calls the
GetLogicalProcessorInformation
twice. Any reason not to start with a buffer of a fix size (eg. 64 entries)? Maybe this initial buffer could be on stack, so it wouldn't really cost anything. On most machines that would cut the number of calls to just 1.The text was updated successfully, but these errors were encountered: