Skip to content

[RFC 2011] Optimize non-consuming operators #98337

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Jun 28, 2022
Merged

[RFC 2011] Optimize non-consuming operators #98337

merged 1 commit into from
Jun 28, 2022

Conversation

c410-f3r
Copy link
Contributor

@c410-f3r c410-f3r commented Jun 21, 2022 •
edited
Loading

Tracking issue: #44838
Fifth step of #96496

The most non-invasive approach that will probably have very little to no performance impact.

Current behaviour

Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located.

// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !(
  { ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100
) {
  panic!( ... );
}

As such, some overhead is likely to occur (Specially with very large chains of conditions).

New behaviour for non-consuming operators

When an operator is known to not take self, then it is possible to capture variables AFTER the condition.

// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !( a > 1 && b < 100 ) {
  { ***try capture `a`*** }
  { ***try capture `b`*** }
  panic!( ... );
}

So the possible impact on the runtime execution time will be diminished.

r? @oli-obk

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jun 21, 2022
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 21, 2022
oli-obk
oli-obk reviewed Jun 21, 2022
View reviewed changes
@oli-obk
Copy link
Contributor

oli-obk commented Jun 21, 2022

@bors r+

@bors
Copy link
Collaborator

bors commented Jun 21, 2022

📌 Commit a0eba66 has been approved by oli-obk

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 21, 2022
@c410-f3r
Copy link
Contributor Author

Thank you @oli-obk

Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 22, 2022
@Dylan-DPC
Rollup merge of rust-lang#98337 - c410-f3r:assert-compiler, r=oli-obk
77732a5 
[RFC 2011] Optimize non-consuming operators

Tracking issue: rust-lang#44838
Fifth step of rust-lang#96496

The most non-invasive approach that will probably have very little to no performance impact.

## Current behaviour

Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located.

```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !(
  { ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100
) {
  panic!( ... );
}
```

As such, some overhead is likely to occur (Specially with very large chains of conditions).

## New behaviour for non-consuming operators

When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition.

```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !( a > 1 && b < 100 ) {
  { ***try capture `a`*** }
  { ***try capture `b`*** }
  panic!( ... );
}
```

So the possible impact on the runtime execution time will be diminished.

r? `@oli-obk`
@Dylan-DPC Dylan-DPC mentioned this pull request Jun 22, 2022
Closed
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 24, 2022
@Dylan-DPC
Rollup merge of rust-lang#98337 - c410-f3r:assert-compiler, r=oli-obk
68c94cd 
[RFC 2011] Optimize non-consuming operators

Tracking issue: rust-lang#44838
Fifth step of rust-lang#96496

The most non-invasive approach that will probably have very little to no performance impact.

## Current behaviour

Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located.

```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !(
  { ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100
) {
  panic!( ... );
}
```

As such, some overhead is likely to occur (Specially with very large chains of conditions).

## New behaviour for non-consuming operators

When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition.

```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !( a > 1 && b < 100 ) {
  { ***try capture `a`*** }
  { ***try capture `b`*** }
  panic!( ... );
}
```

So the possible impact on the runtime execution time will be diminished.

r? ``@oli-obk``
@Dylan-DPC Dylan-DPC mentioned this pull request Jun 24, 2022
Closed
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Jun 28, 2022
@Dylan-DPC
Rollup merge of rust-lang#98337 - c410-f3r:assert-compiler, r=oli-obk
9ed32b1 
[RFC 2011] Optimize non-consuming operators

Tracking issue: rust-lang#44838
Fifth step of rust-lang#96496

The most non-invasive approach that will probably have very little to no performance impact.

## Current behaviour

Captures are handled "on-the-fly", i.e., they are performed in the same place expressions are located.

```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !(
  { ***try capture `a` and then return `a`*** } > 1 && { ***try capture `b` and then return `b`*** } < 100
) {
  panic!( ... );
}
```

As such, some overhead is likely to occur (Specially with very large chains of conditions).

## New behaviour for non-consuming operators

When an operator is known to not take `self`, then it is possible to capture variables **AFTER** the condition.

```rust
// `let a = 1; let b = 2; assert!(a > 1 && b < 100);`

if !( a > 1 && b < 100 ) {
  { ***try capture `a`*** }
  { ***try capture `b`*** }
  panic!( ... );
}
```

So the possible impact on the runtime execution time will be diminished.

r? ```@oli-obk```
@Dylan-DPC Dylan-DPC mentioned this pull request Jun 28, 2022
Closed
@Dylan-DPC Dylan-DPC mentioned this pull request Jun 28, 2022
Merged
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 28, 2022
@bors
Auto merge of rust-lang#98612 - Dylan-DPC:rollup-7tasikc, r=Dylan-DPC
00ebeb8 
Rollup of 9 pull requests

Successful merges:

 - rust-lang#97346 (Remove a back-compat hack on lazy TAIT)
 - rust-lang#98261 (Remove `MAX_SUGGESTION_HIGHLIGHT_LINES`)
 - rust-lang#98337 ([RFC 2011] Optimize non-consuming operators)
 - rust-lang#98384 (Fix RSS reporting on macOS)
 - rust-lang#98420 (translation: lint fix + more migration)
 - rust-lang#98430 (Refactor iter adapters with less macros)
 - rust-lang#98555 (Hermit: Fix initializing lazy locks)
 - rust-lang#98595 (Implement `Send` and `Sync` for `ThinBox<T>`)
 - rust-lang#98597 (Remove unstable CStr/CString change from 1.62 release note)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit ec8477f into rust-lang:master Jun 28, 2022
@rustbot rustbot added this to the 1.64.0 milestone Jun 28, 2022
@fmease fmease added the F-generic_assert `#![feature(generic_assert)]` label Apr 8, 2024
@fmease fmease mentioned this pull request Apr 8, 2024
Open
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@oli-obk oli-obk oli-obk left review comments

Assignees

@oli-obk oli-obk

Labels
F-generic_assert `#![feature(generic_assert)]` S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.64.0
Development

Successfully merging this pull request may close these issues.
6 participants
@c410-f3r @oli-obk @bors @rust-highfive @fmease @rustbot