-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: [offline] implement one-file-per-query #1770
Conversation
0408707
to
891cd45
Compare
Title is not accurate (and wasn't on my PR for a while 😅), since the prepare command is still there (and I think that is the right thing). Also, since this touches the whole cargo-metadata thingy, it may be a good idea to fix #1706 along the way (see latest comment for how it can likely be solved). |
The title was automatically generated from your commit message, which I cherry-picked to keep correct attribution on the parts of your code that were useful. |
Re: the performance of the query macros, I've been testing this branch along with a couple that switch the serialization from Adding the following to the [profile.dev.build-override]
opt-level = 3
debug = false
debug-assertions = false
incremental = false
overflow-checks = false The caching implemented by @LovecraftianHorror in #1684 was actually the biggest performance win for offline mode as it cut the runtime of the macros by roughly a factor of 2-4 over v0.5.10, and is comparable in performance to this branch and its siblings. SQLx 0.5.11 with the caching of However, the total runtime of the macro expansion pass as given by While we probably still want this change for its ergonomic benefits, efforts in optimizing the compile time of SQLx are probably better spent in optimizing the code we generate and not necessarily how we generate it. |
82385f4
to
4c2ef77
Compare
Query data is now stored in .sqlx/{query_hash}.json directly by the macro invocations, rather than first writing to target/sqlx/{input_span_hash}.json and then collecting those into sqlx-data.json separately.
4c2ef77
to
b532eb3
Compare
👋 @abonander Do you still intend to revisit this PR when you have time or would you be open to someone taking over? I see this is quite a long-standing issue. There seem to be only a few tasks outstanding:
I expect merging Or am I underestimating the work left, is there something I missed? |
Regarding |
Well, it took longer than expected but I continued the branch in my fork. It's cleaned up and pretty much finished apart from documentation. If there's any interest, you can view the changes here (didn't want to open a PR without permission): I kept pretty close to the current PR (e.g. kept the offline in-memory caching implementation rather than adapting the version of it from What did I change then? Pretty much what was listed above and some more:
I manually tested
Which confirmed the behaviour should be the same as before in terms of which queries are included or not compared to Take a look if you have the chance and let me know if it's worth finishing this off (just documentation and testing/benchmarking, unless you see anything that needs changing, like the in-memory caching) or pursuing a different direction, such as starting from scratch? |
I'm working on a large refactor for 0.7.0 and we want to land this as part of that release. @cycraig if you'd open a new PR based against |
Completed in #2363 |
continuation of/supercedes #1183
closes #570
closes #1005
cc @jplatte
TODO:
.gitattributes
?)