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
I'm currently working on another performance-critical project that uses this crate. I'm inspecting generated assembly code and noted some possible improvements to this crate. Before I forget all of this, here is a random list of notes:
Using bitvec[index] is bad: because that crate uses the static TRUE/FALSE trick to in the [] operator we have a branch where there shouldn't be one. Use get instead or something like that
First indexing the bitvec and then the data vec does two bound checks. That's bad. Everywhere where we use has_element_at (and it returns true), we should use get_unchecked or so.
Setting or resetting a bit (done via & or | with a mask) is not optimized well. This should (probably be done) with the BTS and BTR instructions on x86. Have too look into this.
(This issue is rather a reminder to myself...)
The text was updated successfully, but these errors were encountered:
I'm currently working on another performance-critical project that uses this crate. I'm inspecting generated assembly code and noted some possible improvements to this crate. Before I forget all of this, here is a random list of notes:
Usingbitvec[index]
is bad: because that crate uses thestatic TRUE/FALSE
trick to in the[]
operator we have a branch where there shouldn't be one. Useget
instead or something like thatFirst indexing the bitvec and then the data vec does two bound checks. That's bad. Everywhere where we usehas_element_at
(and it returnstrue
), we should useget_unchecked
or so.&
or|
with a mask) is not optimized well. This should (probably be done) with the BTS and BTR instructions on x86. Have too look into this.(This issue is rather a reminder to myself...)
The text was updated successfully, but these errors were encountered: