tauri
tauri copied to clipboard
tauri-apps
[bug] cargo-tauri-dev takes exceptionally long
Describe the bug
I first reported this issue in #4315 here
The problem is that executing cargo tauri dev takes a really long time. I can easily compile my whole codebase from scratch (cargo clean && cargo build) in the time that cargo tauri dev takes to open the window. My trunk comes up pretty quickly, so the external command does not seem to be the issue.
Also nothing gets recompiled (watching htop while waiting for cargo tauri dev shows nothing out of order or compiling).
Once the app is shown, saving a file and letting cargo tauri dev re-start the GUI works fast and as expected, but changing nothing and re-executing cargo tauri dev takes again a really long time.
Reproduction
Execute cargo tauri dev.
Expected behavior
GUI is shown in reasonable time.
Platform and versions
Environment
› OS: NixOS 22.11.0 X64
› Node.js: 16.17.1
› npm: 8.15.0
› pnpm: Not installed!
› yarn: Not installed!
› rustup: Not installed!
› rustc: 1.65.0
› cargo: 1.65.0
› Rust toolchain:
Packages
WARNING: no lock files found, defaulting to npm
› @tauri-apps/cli [NPM]: 1.2.2
› @tauri-apps/api [NPM]: Not installed!
› tauri [RUST]: 1.2.3,
› tauri-build [RUST]: 1.2.1,
› tao [RUST]: 0.15.8,
› wry [RUST]: 0.23.4,
App
› build-type: bundle
› CSP: unset
› distDir: ../frontend
› devPath: http://localhost:8080/
package.json not found
App directory structure
├─ types
├─ .git
├─ .github
├─ src-tauri
├─ nix
├─ frontend
└─ target
Stack trace
No response
Additional context
No response
Here's a recording: https://kraut.zone/w/p1F3CkLE2ywcN21CkZkKhZ
I literally went to the kitchen, got something to drink, then went to the kitchen again and put some leftovers into the microwave before the GUI was started.
You'll notice that in the last part of the video, some things were compiled (as shown in the output), but that's literally a second or something like that, not multiple minutes.
I hope that shows what I mean.
Edit: I ran strace on the process, and one finding is that clock_gettime gets called a lot. In 764699 lines of output, 160773 are clock_gettime calls. That's 21%. Not sure whether this is actually the issue, but it seems strange to me.
Seems like a deadlock or maybe the dev watcher is too slow. Can you check again with tauri dev -vv or tauri dev --no-watch?
From what I see, cargo tauri dev -vv does not print anything interesting. It does not print anything during the wait-time.
cargo tauri dev --no-watch does not change anything.
No idea if the ping in the pr worked so i'll add another message here, can you check if this pr fixes it? https://github.com/tauri-apps/tauri/pull/6046
No idea if the ping in the pr worked so i'll add another message here, can you check if this pr fixes it? #6046
You can check patch #6046 this way in your project folder.
# cloning the tauri repo as well as the patch, then
cargo run --manifest-path "[path_to_tauri]/tauri/tooling/cli/Cargo.toml" dev
Thanks for pinging me. The patch from the PR did not fix the issue for me.
Thanks for pinging me. The patch from the PR did not fix the issue for me.
Is there any chance that you could provide me a minimal reproducible example?
Is there any chance that you could provide me a minimal reproducible example?
The slow startup time is also there if I use the tauri project creator helper tool and do nothing more than create-tauri-app && cargo tauri dev!
Or do you mean a minimal reproducible example with my nix setup?
Is there any chance that you could provide me a minimal reproducible example?
The slow startup time is also there if I use the tauri project creator helper tool and do nothing more than
create-tauri-app && cargo tauri dev! Or do you mean a minimal reproducible example with my nix setup?
Ok, I tried cargo create-tauri-app with cargo + yew options. Here is the rec:
https://asciinema.org/a/Datt45kpob3BFOOWvw7RB5iVz
before the patch, the cargo tauri dev stucks at server listening at xxxx:yyyy just the same as your video shows.
but with the patch, it should be ok.
maybe you can use Wireshark to check the TCP communication between Tauri and the webserver. for me, the port is 1420, and 8080 for your case in the video.
Without the patch, the TCP stucks at the second rst packet.
