Having compile time issues? Post here!

[davidpdrsn]

Crates should not be slow to compile due to axum. If you're having compile issues please post a reproduction script here so we can fix it!

Note that compiles have been improved for the upcoming 0.2 release. If you're having issues try depending directly on main.

Known issues

These are the currently known compile time issues:

• A lot of chained .route(...) calls that ends in .boxed() can be slow to compile. We believe this is a rustc bug and don't have a fix for it in axum. See Having compile time issues? Post here! #200 (comment) for a possible workaround.
• Calling Handler::layer multiple times to add several middleware. See Having compile time issues? Post here! #200 (comment). Note that using tower::ServiceBuilder fixes the issue and is the recommended way to add multiple middleware.
• Compile times are slower on 1.56 #399

[sindreij]

I get really slow compile times when using boxed(). The compile-time is dependent on the number of routes, the more the worse the compile-time is.

In my real production-app, the compile time goes from 3 seconds to around a minute when using boxed.

I have a small reproduction here, where the effect is a bit less, but it still takes 10 seconds to compile (and 0.5 seconds without boxed).

/~https://github.com/sindreij/boxed-slow-axum

Update: Using main instead of 0.1.3 fixed it

Update: My bad, it's still slow. I have updated the example-code.

/~https://github.com/sindreij/boxed-slow-axum is now even simpler, and takes multiple minutes to compile on my computer (I stopped the process after 2.5 minutes). Looks like the time is exponential when increasing the number of routes. When not using boxed, it completes in under a second.

[paulzhang5511]

Every time i change the code, the compilation is very slow.

Example:

/~https://github.com/paulzhang5511/axum-compile-slow

[sindreij]

@davidpdrsn My bad, it's still slow. I have updated my original post.

[sindreij]

I also get a similar slowness when using nest also when the router is not boxed.

Example: /~https://github.com/sindreij/boxed-slow-axum/blob/nest/src/main.rs

[davidpdrsn]

Compile times improve when we remove the trait bounds from the methods like route and nest. I'm gonna make a PR that does that later today.

However we cannot remove the bounds from boxed because they're necessary for boxing. So sadly nothing we can do there. Its a rustc bug apparently. I think we should investigate making a minimal reproduction script and filing an issue for rust.

[sindreij]

Okay, thanks. Until it's fixed, I work around it by defining all the routes in one place.

And btw, thanks for a great framework, it's really nice to use.

[davidpdrsn]

@paulzhang5511 I just merged #220 which should help with your issue, if you remove .boxed() which is still problematic as mentioned above. Honestly not sure thats something we can fix in axum 😕

[ufoscout]

FYI, another workaround is also to declare all routes as .boxed().

E.g., this takes years to compile:

    let app = Router::new()
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a))
        .route("/a", get(get_a)).boxed();

and this is extremely fast:

    let app = Router::new()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed()
        .route("/a", get(get_a)).boxed();

BTW, I am not sure whether it has any runtime performance hit.

[davidpdrsn]

BTW, I am not sure whether it has any runtime performance hit.

It will have some perf impact but exactly how big I don't know. That'd require benchmarking which I haven't done.