Diesel takes forever to compile with 32-column-tables as of #2182

[Ten0]

Setup

Versions

• Rust: latest stable (1.45.2)
• Diesel: latest master (8d3c955)
• Database:
• Operating System: ArchLinux

Feature Flags

• diesel: /

Problem Description

As of 8d3c955 (#2182), diesel takes forever to compile when default features are enabled.

What are you trying to accomplish?

git clone --single-branch https://github.com/diesel-rs/diesel.git
cd diesel/diesel
cargo check --no-default-features --features "32-column-tables"

What is the expected output?

Compiles successfully

What is the actual output?

After ~1h with 64-column-tables (And so far, 15m with 32-column-tables)

    Updating crates.io index
   Compiling proc-macro2 v1.0.19
   Compiling unicode-xid v0.2.1
   Compiling syn v1.0.38
   Compiling byteorder v1.3.4
    Checking itoa v0.4.6
   Compiling quote v1.0.7
   Compiling diesel_derives v2.0.0 (/path/to/diesel/diesel_derives)
    Checking diesel v2.0.0 (/path/to/diesel/diesel)
^C  Building [===================================================>     ] 13/14: diesel

Are you seeing any additional errors?

no

[weiznich]

Technically that's a closed because cannot reproduce. I can successful compile diesel with default features, so I "achieved" your "expected output" section. 😜
Jokes beside: Yes compiling diesel with default features takes to much time and that's unexpected for me.
Using only the default 16-column variant let me build diesel from scratch in 39 seconds, while using the 32-columns variant takes 17 mins. That's not expected or in any way acceptable.

We may want to raise a bug in rustc for that. I think the will require a minimal standalone example so someone needs to sit down and build one using the strategies listed here. It would be great if you can provide such a condensed example.

I currently (at least till mid of September) do not have the time to sit down and build such a minimal example or find the exact reason why this happens. Till then the workaround is: Either wait till diesel is build for the first time, after that is should be faster or try to use only the the minimal 16-columns feature.

[weiznich]

Additional notes:
As this is related to the tuple size till where diesel implements built-in traits it's likely caused by some impl in this file. @Ten0 It would be great if you can have a look there and just start remove some of the impl's to see which impl exactly is causing this enormous compile time. I would just start by commenting them out one by one (or even in a binary search way) and see if a) diesel continues to compile and b) the regression reproduces (I don't think you need to wait for a successful build in all cases, just see if it fails quickly if not assume it will be successful. ). I think this should it make easier to report that to upstream rust (as providing a minimal standalone example should be "easy" then) and also allow us to thing about potential workarounds for replacing that impl with something that does not lead to that slow down in compile times.

[weiznich]

I've used rustc's profiling infrastructure to see where the time is spend.
The following output is for the 32-columns feature:

+-------------------------+-----------+-----------------+---------+------------+------------+--------------+-----------------------+
| Item                    | Self time | % of total time | Time    | Item count | Cache hits | Blocked time | Incremental load time |
+-------------------------+-----------+-----------------+---------+------------+------------+--------------+-----------------------+
| specialization_graph_of | 842.80s   | 97.172          | 842.84s | 136        | 0          | 0.00ns       | 0.00ns                |
+-------------------------+-----------+-----------------+---------+------------+------------+--------------+-----------------------+

This is from building without the 32-columns feature:

+-------------------------+-----------+-----------------+-------+------------+------------+--------------+-----------------------+
| Item                    | Self time | % of total time | Time  | Item count | Cache hits | Blocked time | Incremental load time |
+-------------------------+-----------+-----------------+-------+------------+------------+--------------+-----------------------+
| specialization_graph_of | 2.00s     | 19.308          | 2.09s | 136        | 0          | 0.00ns       | 0.00ns                |
+-------------------------+-----------+-----------------+-------+------------+------------+--------------+-----------------------+
| typeck                  | 1.86s     | 17.923          | 2.03s | 1795       | 0          | 0.00ns       | 0.00ns                |
+-------------------------+-----------+-----------------+-------+------------+------------+--------------+-----------------------+
| expand_crate            | 1.20s     | 11.563          | 1.32s | 1          | 0          | 0.00ns       | 0.00ns                |
+-------------------------+-----------+-----------------+-------+------------+------------+--------------+-----------------------+

Both times the output for passes where > 10% of the time is spend. So it seems like for the 32-columns feature the time is more or less completely spend inside of the specialization_graph_of pass. If we find a minimal example we should certainly report that upstream because that looks like some non linear algorithm is used there.

[weiznich]

Ok I think I've found the problem. Removing this impl will bring the compile times back to a reasonable level. That's obviously no solution that we can merge, but at least we know what's the cause of this. Next steps:

• Extract a minimal reproducible problem based on this and report it to upstream/rustc
• Find an alternative way to write the trait bounds there. I would guess those recursive things is problematic?

[bnjjj]

I have the same issue, cannot compile on my macbook pro :( Looks like it hangs forever. I'm sad lol

[weiznich]

@bnjjj Please elaborate what you want to tell us with your comment. Otherwise please do not comment: "Happens for me too" on random issues, as this does not add something to the discussion there.

[bnjjj]

Oh ok sorry my bad, I just confirm that on my macbook pro when I upgrade to the latest version of Diesel as the title of this issue mention here the compile time is very very long.