Rider for Unreal Engine Engine files processing taking too long and doesnt show all folders
I work on UE plugins mostly, and that means i often create new host projects, import plugins and have several projects open at a time.
I have been using jetbrains products for years now, but just can't seem to use them for UE plugin development in a day to day manner.
The biggest problem I am experiencing are very slow first loads of a project, I have a pretty good computer and it takes about 5-10 minutes to stop loading, and I can edit files after about 2 minutes, which if very very complicated when your trying to edit something on the fly, test things out, migrate it to a new project and wait again.
Is there any way to speed up the process? Cache stuff? Ignore stuff? As far as I can see the projects are taking most time loading UE files.
The other big thing that happens is since plugin files are migrated into the folder "by hand" and not through the IDE, the editor often doesnt see them, and reload all from disk doesnt help.
VS2019 seems to load pretty fast and I can get started with code in seconds, if I could get to that level of efficiency with Rider UE i would definitely be using it more.
Any suggestoins on how to make this more efficient?
Please sign in to leave a comment.
Hi Tony,
Thank you for creating this request.
Did you measure the time on warm-start or cold-start?
It worth noting that antivirus software can affect Rider performance on Windows. One can try configuring antivirus exception list and watch if it could help.
https://rider-support.jetbrains.com/hc/en-us/articles/360006365380-How-Antivirus-Software-Affects-Rider-s-Performance-on-Windows-
As for the adding file not through the IDE, this is a by-design behavior. Rider does not listen to changes in the file system. To make newly added files to appear in the project model, one needs to regenerate vcxproj/sln files.
Kind regards,
Sofia.
Thank you for your answer
Warm start is faster, that is true, but it seems an awful lot of time spent on UE engine files (7 minutes) on a cold start, which are generally unchanged between projects. As I said, I mostly do "host" projects for plugins, so most of my starts are cold.
Antivirus exclusions didn't seem to help much, I've done the "configure automatically" thingy every time anyway
Out of editor files are understandable, and I can confirm it does work when i regenerate + reload from disk.
As the UE projects are large, and Rider, indeed, spends a lot of time on indexing UE files. We have plans to improve this.
It worth noting Game files are indexed far faster, and one can start editing game code even when Unreal Engine files indexing is in progress.
That's fine, except that when it's trying to index an effectively (through referenced assets in the scene) several gigabyte Scene uasset, it eats up all of my 64 gb of RAM and 90+% of my CPU (and I have a VERY powerful machine), so keypresses literally take up to 20 seconds to register in the IDE. Honestly, it almost makes the IDE unusable on large projects. I love JetBrains IDEs, and am a HUGE fan of Rider, so I'd love to get around this issue so I can use it, but... Sofia Byzova
Hi Kyle,
Could you please collect and share .net memory snapshot and a screenshot of a process monitor with the problem (CPU usage) process visible on it?
To collect a snapshot, do:
1. wait until Rider starts using a massive amount of memory,
2. then call
Help -> Diagnostic Tools -> Capture Backend Memory Snapshot,3. wait until the process ended and you see a notification in the bottom right corner.
4. share a collected snapshot via https://uploads.jetbrains.com/ and let me know an "upload id".
Thanks!
I can do that. Just waiting ultimately fixed it, I just couldn't use my computer at all for several hours while it completed.
I am also having the same problem as you, where Rider will you up almost all of my RAM.
@Kyle Richter Would it be possible for you to share that big uasset file with us (if you prefer we can sign an NDA)?
Hi Kyle Richter,
It appeared that memory snapshot is useless in this case. Could you please collect a timeline backend performance snapshot instead? A guide can be found here in the "Embedded profiler" section: https://rider-support.jetbrains.com/hc/en-us/articles/207490549-Rider-Profiling-Instructions-NET-process-.
Thank you.
Same problem here, it takes so far 2-3 hrs and is not half way complete yet, and also uses all available memory causing itself and other processes to crash. Whatever you are doing here, it is not working well for large projects. Do you test this internally on a realistically sized Unreal project including engine source and 50GB+ of assets?
I searched in the settings for something that will allow me to disable this processing, or exclude assets from it, but could not see anything.
Hello William Woodbury,
Please open an issue on our tracker using Help->Report a Bug and attach the Rider logs when prompted. We'll also need a backend snapshot. You can follow this article to collect the snapshot. The relevant part is "Windows: Embedded profiler" (you should use Profile Backend with Timeline). You can send us the snapshot using the Upload Service - just let us know the generated Upload ID.
It would help if you could attach to the issue a screenshot of Rider's background tasks. I'm attaching a screenshot as a reference.
I have the same problem too
Is there any way to fix it temporarily by setting or something?
Find out that uncheck Enable Blueprints Support in Settings->Languages & Frameworks -> C++ -> Unreal Engine can fix this
@603010999 , Uncheck `Enable Blueprints Support` indeed fix the memory consumption problem!!
Maybe the Rider is analysing the big uasset for `Blueprint c++ code reflection`?
wumo Does this happen with the latest 2021.1 build or the previous 2020.3 build?
https://rider-support.jetbrains.com/hc/en-us/community/posts/360008398040/comments/360002799640
The latest 2021.1 build.
I got the same problem when my team transferred Uassets files to lfs.
Hello Acterix Ng,
Could you send us additional information described in this issue? It would help if you could specify the number of Uassets stored under LFS for this project.
Around 30000 files
It's still a problem for me. It uses all the memory and takes forever to "cache processing".