Literally initializing [&str; N]
(using proc macro) doesn't scale, rustc
consumes huge amounts of time and RAM (stable and nightly)
#90445
Labels
C-bug
Category: This is a bug.
Hi Rust folks,
I'm using a procedural macro to read and preprocess some strings to be stored in an application without hitting the disk at any intermediate point. The macro outputs a
TokenStream
for a literal fixed-size array of string slices. When scaling up the amount of strings to a moderately high count (100k), I noticed something strange: compiling the application suddenly takes orders of magnitude more time and makes the compiler consumes almost 40 GiB of RAM in the process. Here's a MWE, for both the proc macrolib
and the consumer binarybin
:lib/Cargo.toml
:lib/src/lib.rs
:bin/Cargo.toml
:bin/src/main.rs
:Compiling the above takes many minutes, compared to just some seconds when the issue does not occur (see cases below). The memory consumption also peaks very high (truncated from the start, there's a slow increase over many minutes):
This issue is present on both latest stable and nightly (see versions used below), using both debug and release builds. In my project I have
lto = true
andopt-level = "z"
as well, but neither helps. RunningRUSTFLAGS="-Z time-passes" cargo build
on nightly reveals that most of the time is spent on some borrow checking routine:I have also verified that it is not the macro that causes the hang by using proc-macro-error to emit a warning just as the macro is about to return the final
TokenStream
. The warning is emitted right away, before memory hogging begins.From my testing, with the same element count, the issue does not occur, when:
&[...]
).&str
, compilation happens in seconds with e.g.u32
.This leads me to believe that the references of the
&str
types are at fault, but I don't have enough experience inrustc
internals to say anything more than that something doesn't scale (quadratic time?).Meta
rustc +stable --version --verbose
:rustc +nightly --version --verbose
:Backtrace
No backtrace, compilation does eventually succeed given enough time and memory.
The text was updated successfully, but these errors were encountered: