mirror of
https://github.com/oxc-project/oxc.git
synced 2026-11-04 10:29:58 +00:00
YT
03d6f656d9
## Summary On Linux, every `oxlint` run waits 20–40 ms when it creates its first papaya map. This PR removes the wait for both the CLI and the npm package by disabling `fast-barrier` feature of the papaya crate. It also adds a `cargo deny` rule that fails if any crate enables the feature again so we can notice it. ## Why it waits With `fast-barrier`, `seize::Collector::new()` calls `membarrier(MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED)`. If the process already has more than one thread, the kernel waits for an RCU grace period before it returns ([kernel/sched/membarrier.c](https://github.com/torvalds/linux/blob/v6.12/kernel/sched/membarrier.c#L442-L470)). `oxc_linter` has one papaya map: [`modules_by_path`](https://github.com/oxc-project/oxc/blob/faa75d8a8dff299eb9607ae65d04dfb163c28a8c/crates/oxc_linter/src/service/runtime.rs#L59-L66), the module graph that the import plugin uses for rules across files, such as `import/no-cycle`. The map is a field of [`Runtime`](https://github.com/oxc-project/oxc/blob/faa75d8a8dff299eb9607ae65d04dfb163c28a8c/crates/oxc_linter/src/service/runtime.rs#L45), which holds the state of one lint run. [`LintService::new()`](https://github.com/oxc-project/oxc/blob/faa75d8a8dff299eb9607ae65d04dfb163c28a8c/crates/oxc_linter/src/service/mod.rs#L68-L71) creates the `Runtime` once per run. [`Runtime::new()`](https://github.com/oxc-project/oxc/blob/faa75d8a8dff299eb9607ae65d04dfb163c28a8c/crates/oxc_linter/src/service/runtime.rs#L208) first starts the rayon thread pool ([#L227](https://github.com/oxc-project/oxc/blob/faa75d8a8dff299eb9607ae65d04dfb163c28a8c/crates/oxc_linter/src/service/runtime.rs#L227)), and then it creates the map ([#L268](https://github.com/oxc-project/oxc/blob/faa75d8a8dff299eb9607ae65d04dfb163c28a8c/crates/oxc_linter/src/service/runtime.rs#L268)). So the main thread waits on every run. This happens even with the default config, which does not use the import plugin. The npm package waits too. Creating the map earlier would not fix it: the binding does not run `main()`, and Node.js already runs several threads when it loads the binding. ## Results I measured `oxlint` with its default rules on three inputs: - 3 files: a project with three files of 1–4 lines each, so a run is almost only fixed cost. - excalidraw: 590 files from [excalidraw](https://github.com/excalidraw/excalidraw/tree/f6d85bc80fe328e8f472636eb0d541f7bb891aa0) (`excalidraw-app` and `packages`). - vscode `src`: 4,662 files from [vscode 1.100.0](https://github.com/microsoft/vscode/tree/19e0f9e681ecb8e5c09d8784acaa601316ca4571). Each input ran with 1 and 8 threads, with the CLI and with the npm package, so there are 12 cases. The machine is Linux x86_64 (AMD Zen 4, 8 vCPUs), and each bar is the mean of 30 runs. <img width="2300" height="1520" alt="image" src="https://github.com/user-attachments/assets/943b9ac4-9335-4ea2-b94d-498373042fae" /> ## Is anything slower? With `fast-barrier`, the registration at startup lets every `pin()` (one per map call) use a `Relaxed` store. This is the fast path. Without `fast-barrier`, seize uses its portable barriers, which `oxlint` already uses on macOS: each pin does a `SeqCst` store (`xchg` on x86_64), and nothing has to register at startup. To find how much time the fast path saves, I ran three builds on vscode `src` with 8 threads (mean of 30 runs per build, in turn): | Build | `fast-barrier` | Waits at startup | Wall time | |---|---|---|---| | Before this PR | on | yes | 219.6 ms | | Early registration\* | on | no | 191.8 ms | | This PR | off | no | 191.9 ms | \* Before this PR, plus one map created at the start of `main()`, so the registration happens before the thread pool starts. - Before this PR → Early registration: the startup wait, 27.9 ms. - Early registration → This PR: the time that the fast path saves, 0.2 ms, too small to measure. - With `--import-plugin` (9,317 map calls per run), the same difference is 1.8 ms. Windows also loses its fast path, but Windows has no startup wait to remove. I did not measure Windows. --- AI disclosure: I used an AI coding assistant to run the measurements and to draft this description. I reviewed the change, the data, and this text.
262 lines
11 KiB
TOML
262 lines
11 KiB
TOML
# This template contains all of the possible sections and their default values
|
|
|
|
# Note that all fields that take a lint level have these possible values:
|
|
# * deny - An error will be produced and the check will fail
|
|
# * warn - A warning will be produced, but the check will not fail
|
|
# * allow - No warning or error will be produced, though in some cases a note
|
|
# will be
|
|
|
|
# The values provided in this template are the default values that will be used
|
|
# when any section or field is not specified in your own configuration
|
|
|
|
# This section is considered when running `cargo deny check advisories`
|
|
# More documentation for the advisories section can be found here:
|
|
# https://embarkstudios.github.io/cargo-deny/checks/advisories/cfg.html
|
|
[advisories]
|
|
# The path where the advisory database is cloned/fetched into
|
|
db-path = "~/.cargo/advisory-db"
|
|
# The url(s) of the advisory databases to use
|
|
db-urls = ["https://github.com/rustsec/advisory-db"]
|
|
# The lint level for crates that have been yanked from their source registry
|
|
yanked = "warn"
|
|
# A list of advisory IDs to ignore. Note that ignored advisories will still
|
|
# output a note when they are encountered.
|
|
ignore = []
|
|
# Threshold for security vulnerabilities, any vulnerability with a CVSS score
|
|
# lower than the range specified will be ignored. Note that ignored advisories
|
|
# will still output a note when they are encountered.
|
|
# * None - CVSS Score 0.0
|
|
# * Low - CVSS Score 0.1 - 3.9
|
|
# * Medium - CVSS Score 4.0 - 6.9
|
|
# * High - CVSS Score 7.0 - 8.9
|
|
# * Critical - CVSS Score 9.0 - 10.0
|
|
# severity-threshold =
|
|
|
|
# If this is true, then cargo deny will use the git executable to fetch advisory database.
|
|
# If this is false, then it uses a built-in git library.
|
|
# Setting this to true can be helpful if you have special authentication requirements that cargo-deny does not support.
|
|
# See Git Authentication for more information about setting up git authentication.
|
|
# git-fetch-with-cli = true
|
|
|
|
# This section is considered when running `cargo deny check licenses`
|
|
# More documentation for the licenses section can be found here:
|
|
# https://embarkstudios.github.io/cargo-deny/checks/licenses/cfg.html
|
|
[licenses]
|
|
# List of explicitly allowed licenses
|
|
# See https://spdx.org/licenses/ for list of possible licenses
|
|
# [possible values: any SPDX 3.11 short identifier (+ optional exception)].
|
|
allow = [
|
|
"Apache-2.0",
|
|
"BSD-3-Clause",
|
|
"ISC",
|
|
"MIT",
|
|
"MIT-0",
|
|
"MPL-2.0",
|
|
"OpenSSL",
|
|
"Unicode-DFS-2016",
|
|
"Unicode-3.0",
|
|
"CDLA-Permissive-2.0",
|
|
"BSL-1.0",
|
|
]
|
|
# The confidence threshold for detecting a license from license text.
|
|
# The higher the value, the more closely the license text must be to the
|
|
# canonical license text of a valid SPDX license file.
|
|
# [possible values: any between 0.0 and 1.0].
|
|
confidence-threshold = 0.8
|
|
# Allow 1 or more licenses on a per-crate basis, so that particular licenses
|
|
# aren't accepted for every possible crate as with the normal allow list
|
|
exceptions = [
|
|
# Each entry is the crate and version constraint, and its specific allow
|
|
# list
|
|
{ allow = ["Zlib"], name = "foldhash", version = "*" },
|
|
]
|
|
|
|
# Some crates don't have (easily) machine readable licensing information,
|
|
# adding a clarification entry for it allows you to manually specify the
|
|
# licensing information
|
|
[[licenses.clarify]]
|
|
# The name of the crate the clarification applies to
|
|
name = "ring"
|
|
# The optional version constraint for the crate
|
|
version = "*"
|
|
# The SPDX expression for the license requirements of the crate
|
|
expression = "MIT AND ISC AND OpenSSL"
|
|
# One or more files in the crate's source used as the "source of truth" for
|
|
# the license expression. If the contents match, the clarification will be used
|
|
# when running the license check, otherwise the clarification will be ignored
|
|
# and the crate will be checked normally, which may produce warnings or errors
|
|
# depending on the rest of your configuration
|
|
license-files = [
|
|
# Each entry is a crate relative path, and the (opaque) hash of its contents
|
|
{ path = "LICENSE", hash = 0xbd0eed23 },
|
|
]
|
|
|
|
[licenses.private]
|
|
# If true, ignores workspace crates that aren't published, or are only
|
|
# published to private registries.
|
|
# To see how to mark a crate as unpublished (to the official registry),
|
|
# visit https://doc.rust-lang.org/cargo/reference/manifest.html#the-publish-field.
|
|
ignore = false
|
|
# One or more private registries that you might publish crates to, if a crate
|
|
# is only published to private registries, and ignore is true, the crate will
|
|
# not have its license(s) checked
|
|
registries = [
|
|
|
|
# "https://sekretz.com/registry
|
|
]
|
|
|
|
# This section is considered when running `cargo deny check bans`.
|
|
# More documentation about the 'bans' section can be found here:
|
|
# https://embarkstudios.github.io/cargo-deny/checks/bans/cfg.html
|
|
[bans]
|
|
# Lint level for when multiple versions of the same crate are detected
|
|
multiple-versions = "warn"
|
|
# Lint level for when a crate version requirement is `*`
|
|
wildcards = "allow"
|
|
# The graph highlighting used when creating dotgraphs for crates
|
|
# with multiple versions
|
|
# * lowest-version - The path to the lowest versioned duplicate is highlighted
|
|
# * simplest-path - The path to the version with the fewest edges is highlighted
|
|
# * all - Both lowest-version and simplest-path are used
|
|
highlight = "all"
|
|
# The default lint level for `default` features for crates that are members of
|
|
# the workspace that is being checked. This can be overridden by allowing/denying
|
|
# `default` on a crate-by-crate basis if desired.
|
|
workspace-default-features = "allow"
|
|
# The default lint level for `default` features for external crates that are not
|
|
# members of the workspace. This can be overridden by allowing/denying `default`
|
|
# on a crate-by-crate basis if desired.
|
|
external-default-features = "allow"
|
|
# List of crates that are allowed. Use with care!
|
|
allow = [
|
|
# { name = "ansi_term", version = "=0.11.0" },
|
|
]
|
|
# List of crates to deny
|
|
deny = [
|
|
|
|
# Each entry the name of a crate and a version range. If version is
|
|
# not specified, all versions will be matched.
|
|
# { name = "ansi_term", version = "=0.11.0" },
|
|
#
|
|
# Wrapper crates can optionally be specified to allow the crate when it
|
|
# is a direct dependency of the otherwise banned crate
|
|
# { name = "ansi_term", version = "=0.11.0", wrappers = [] },
|
|
]
|
|
|
|
# List of features to allow/deny
|
|
# Each entry the name of a crate and a version range. If version is
|
|
# not specified, all versions will be matched.
|
|
# [[bans.features]]
|
|
# name = "reqwest"
|
|
# Features to not allow
|
|
# deny = ["json"]
|
|
# Features to allow
|
|
# allow = [
|
|
# "rustls",
|
|
# "__rustls",
|
|
# "__tls",
|
|
# "hyper-rustls",
|
|
# "rustls",
|
|
# "rustls-pemfile",
|
|
# "rustls-tls-webpki-roots",
|
|
# "tokio-rustls",
|
|
# "webpki-roots",
|
|
# ]
|
|
# If true, the allowed features must exactly match the enabled feature set. If
|
|
# this is set there is no point setting `deny`
|
|
# exact = true
|
|
|
|
# Certain crates/versions that will be skipped when doing duplicate detection.
|
|
skip = [
|
|
|
|
# { name = "ansi_term", version = "=0.11.0" },
|
|
]
|
|
# Similarly to `skip` allows you to skip certain crates during duplicate
|
|
# detection. Unlike skip, it also includes the entire tree of transitive
|
|
# dependencies starting at the specified crate, up to a certain depth, which is
|
|
# by default infinite.
|
|
skip-tree = [
|
|
|
|
# { name = "ansi_term", version = "=0.11.0", depth = 20 },
|
|
]
|
|
|
|
# papaya enables seize's `fast-barrier` feature by default. On Linux it makes seize register
|
|
# `MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED` when the first collector is created, and in a
|
|
# multi-threaded process the kernel then waits for an RCU grace period (tens of ms, on every
|
|
# oxlint run). The workspace disables papaya's default features. Cargo features are additive,
|
|
# so this rule fails if any other crate enables the feature again and helps us notice that.
|
|
[[bans.features]]
|
|
crate = "seize"
|
|
deny = ["fast-barrier"]
|
|
|
|
# This section is considered when running `cargo deny check sources`.
|
|
# More documentation about the 'sources' section can be found here:
|
|
# https://embarkstudios.github.io/cargo-deny/checks/sources/cfg.html
|
|
[sources]
|
|
# Lint level for what to happen when a crate from a crate registry that is not
|
|
# in the allow list is encountered
|
|
unknown-registry = "warn"
|
|
# Lint level for what to happen when a crate from a git repository that is not
|
|
# in the allow list is encountered
|
|
unknown-git = "warn"
|
|
# List of URLs for allowed crate registries. Defaults to the crates.io index
|
|
# if not specified. If it is specified but empty, no registries are allowed.
|
|
allow-registry = ["https://github.com/rust-lang/crates.io-index"]
|
|
# List of URLs for allowed Git repositories
|
|
allow-git = []
|
|
|
|
[sources.allow-org]
|
|
# 1 or more github.com organizations to allow git sources for
|
|
# github = [""]
|
|
# 1 or more gitlab.com organizations to allow git sources for
|
|
# gitlab = [""]
|
|
# 1 or more bitbucket.org organizations to allow git sources for
|
|
# bitbucket = [""]
|
|
|
|
[graph]
|
|
# If 1 or more target triples (and optionally, target_features) are specified,
|
|
# only the specified targets will be checked when running `cargo deny check`.
|
|
# This means, if a particular package is only ever used as a target specific
|
|
# dependency, such as, for example, the `nix` crate only being used via the
|
|
# `target_family = "unix"` configuration, that only having windows targets in
|
|
# this list would mean the nix crate, as well as any of its exclusive
|
|
# dependencies not shared by any other crates, would be ignored, as the target
|
|
# list here is effectively saying which targets you are building for.
|
|
targets = [
|
|
|
|
# The triple can be any string, but only the target triples built in to
|
|
# rustc (as of 1.40) can be checked against actual config expressions
|
|
# { triple = "x86_64-unknown-linux-musl" },
|
|
# You can also specify which target_features you promise are enabled for a
|
|
# particular target. target_features are currently not validated against
|
|
# the actual valid features supported by the target architecture.
|
|
# { triple = "wasm32-unknown-unknown", features = ["atomics"] },
|
|
]
|
|
# When creating the dependency graph used as the source of truth when checks are
|
|
# executed, this field can be used to prune crates from the graph, removing them
|
|
# from the view of cargo-deny. This is an extremely heavy hammer, as if a crate
|
|
# is pruned from the graph, all of its dependencies will also be pruned unless
|
|
# they are connected to another crate in the graph that hasn't been pruned,
|
|
# so it should be used with care. The identifiers are [Package ID Specifications]
|
|
# (https://doc.rust-lang.org/cargo/reference/pkgid-spec.html)
|
|
# exclude = []
|
|
# If true, metadata will be collected with `--all-features`. Note that this can't
|
|
# be toggled off if true, if you want to conditionally enable `--all-features` it
|
|
# is recommended to pass `--all-features` on the cmd line instead
|
|
all-features = false
|
|
# If true, metadata will be collected with `--no-default-features`. The same
|
|
# caveat with `all-features` applies
|
|
no-default-features = false
|
|
|
|
# If set, these feature will be enabled when collecting metadata. If `--features`
|
|
# is specified on the cmd line they will take precedence over this option.
|
|
# features = []
|
|
|
|
[output]
|
|
# When outputting inclusion graphs in diagnostics that include features, this
|
|
# option can be used to specify the depth at which feature edges will be added.
|
|
# This option is included since the graphs can be quite large and the addition
|
|
# of features from the crate(s) to all of the graph roots can be far too verbose.
|
|
# This option can be overridden via `--feature-depth` on the cmd line
|
|
feature-depth = 1
|