Task - Improve performance using build enhancment and improve caching mechanism
I understand that my RFC was too large to process. I'm going to focus on two steps for now.
- Build enhancement (
incremental=false,strip=debuginfo, override build opt of other dependencies) - Research the best solution to replace JSON caching with, probably using SQLite. To perform those tasks, I need to know whether you have a test suite I can run, and benchmark, and any contribution direction.
@cordx56 @MuntasirSZN I would like to start working at the earliest, so I would appreciate your response.
@avifenesh Thank you!
We can run test analysis by running the rustowl check command.
JSON caching is not implemented (but the code saving the JSON file exists!?) so I would appreciate it if you implemented caching!
Also rayon and dashmap crates, for parallelism.
🤖 Bot: Issue has not seen activity in 30 days and will therefore be marked as stale. It will be closed in 7 days if no further response is found.
Add cache done by @cordx56. Simple, but works.
@cordx56 i have a thought. Currently, when i open a rust file, rustowl checks whole project. But what if, it analyzes anything about that file (and caches it). This will speed up the dx greatly.
This needs a rustowl check --file option, and refactor the core a bit.
@MuntasirSZN If my knowledge is correct, checking a single file is difficult. The reason is that the compilation unit in Rust is a crate, not a file.
Maybe we can close this issue and move on to new ones. @avifenesh how do you think?
@cordx56 im sorry, wasn't around lately so i dont know what was implemented. But in any case, if we implemented cache and its doing its best, then it can be close. My idea was to create a persistent high performance cache with easy to create entities, and do some research on how it can be done at the beginning on one file needs, while keep iterating in the background on the other, or whether its possible to work in a way that evaluate base on other scopes other then file vs. crate, maybe its even possible to narrow down to function and built upon, and this way to offload parts to more workers simultaneously. In addition to check cached entities for each iteration, eliminating some recursion. But it might be over engineering if its works good and fast enough, and maybe the next step that users care about are completely different. Maybe we can research over FFI boundaries checks for example - if you find it possible, it will be a development must use tool for so many projects, much more the visualization.
Thank you for your valuable feedback, @avifenesh ! Let's open a new issue for cache improvements and consider possible enhancements. For now, I close this issue.