Improve shootout-reverse-complement.rs using unsafe code#18056
Merged
bors merged 2 commits intorust-lang:masterfrom Oct 17, 2014
Merged
Improve shootout-reverse-complement.rs using unsafe code#18056bors merged 2 commits intorust-lang:masterfrom
bors merged 2 commits intorust-lang:masterfrom
Conversation
Contributor
|
|
Contributor
There was a problem hiding this comment.
This is probably faster storing raw pointers (and is somewhat simpler):
struct TwoSidedIterator<'a, T: 'a> {
start: *mut T,
end: *mut T,
_marker: marker::ContravariantLifetime<'a>
}
fn new(x: &'a mut [T]) -> TwoSideIterator<'a, T> {
let start = x.as_mut_ptr();
let end = if x.len() == 0 {
start
} else {
unsafe {start.offset(x.len() - 1)}
};
TwoSideIterator {
start: start,
end: end,
_marker: marker::ContravariantLifetime
}
}
fn next(&mut self) -> Option<(&'a mut T, &'a mut T)> {
if self.start < self.end {
let ret = unsafe { (&mut *self.start, &mut *self.end) };
self.start = self.start.offset(1);
self.end = self.end.offset(-1);
ret
} else {
None
}
}If not that, decrementing self.last instead of doing this subtraction would be better (would avoid the need to store nb too).
Contributor
Author
|
After using pointers in so better :) On the other hand, the code is trickier:
Finally, such a modification may be interesting to do in |
15 tasks
bors
added a commit
that referenced
this pull request
Oct 17, 2014
…vement, r=alexcrichton This is some improvement as asked and discused here: http://www.reddit.com/r/rust/comments/2j2ij3/benchmark_improvement_reverse_compliment/ Before: ``` real 0m0.396s user 0m0.280s sys 0m0.112s ``` after: ``` real 0m0.293s user 0m0.216s sys 0m0.076s ``` best C version: ``` real 0m0.135s user 0m0.132s sys 0m0.060s ``` Another possibility will be to add a `DoubleEndedIterator::next_two_side()` with a deffault implementation, and specialising it for slices, and use it here (`MutableSlice::reverse()` can then become safe). This benchmark will then be safe. What do you think?
lnicola
pushed a commit
to lnicola/rust
that referenced
this pull request
Sep 25, 2024
…r=Veykril
Use more correct handling of lint attributes
The previous analysis was top-down, and worked on a single file (expanding macros). The new analysis is bottom-up, starting from the diagnostics and climbing up the syntax and module tree.
While this is more efficient (and in fact, efficiency was the motivating reason to work on this), unfortunately the code was already fast enough. But luckily, it also fixes a correctness problem: outline parent modules' attributes were not respected for the previous analysis. Case lints specifically did their own analysis to accommodate that, but it was limited to only them. The new analysis works on all kinds of lints, present and future.
It was basically impossible to fix the old analysis without rewriting it because navigating the module hierarchy must come bottom-up, and if we already have a bottom-up analysis (including syntax analysis because modules can be nested in other syntax elements, including macros), it makes sense to use only this kind of analysis.
Few other bugs (not fundamental to the previous analysis) are also fixed, e.g. overwriting of lint levels (i.e. `#[allow(lint)] mod foo { #[warn(lint)] mod bar; }`.
After this PR is merged I intend to work on an editor command that does workspace-wide diagnostics analysis (that is, `rust-analyzer diagnostics` but from your editor and without having to spawn a new process, which will have to analyze the workspace from scratch). This can be useful to users who do not want to enable check on save because of its overhead, but want to see workspace wide diagnostics from r-a (or to maintainers of rust-analyzer).
Closes rust-lang#18086.
Closes rust-lang#18081.
Fixes rust-lang#18056.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is some improvement as asked and discused here: http://www.reddit.com/r/rust/comments/2j2ij3/benchmark_improvement_reverse_compliment/
Before:
after:
best C version:
Another possibility will be to add a
DoubleEndedIterator::next_two_side()with a deffault implementation, and specialising it for slices, and use it here (MutableSlice::reverse()can then become safe). This benchmark will then be safe.What do you think?