Hello,
I recently bought RemedyBG to try it out since Visual Studio has been so unstable lately. Have very much enjoyed the switch. Very fast to do everything I need it to and intuitive, even if it has some parts that are rough around the edges.
One thing I did notice is that the memory usage when starting up the UE4Editor is that memory usage suddenly increased very quickly. This may be down to UE4 being so sloppily put together, and not RemedyBG's code that is at fault, but I felt it's worth reporting.
While starting up the UE4 Edtior:
After it's finished starting up:
After a few minutes:
Unreal loads a truckload of DLLs on startup, so I could see the memory usage climbing in response to that, although since it dips down after a few minutes I'm not sure what Remedy is doing memory wise.
I recently bought RemedyBG to try it out since Visual Studio has been so unstable lately. Have very much enjoyed the switch. Very fast to do everything I need it to and intuitive, even if it has some parts that are rough around the edges.
One thing I did notice is that the memory usage when starting up the UE4Editor is that memory usage suddenly increased very quickly. This may be down to UE4 being so sloppily put together, and not RemedyBG's code that is at fault, but I felt it's worth reporting.
While starting up the UE4 Edtior:
After it's finished starting up:
After a few minutes:
Unreal loads a truckload of DLLs on startup, so I could see the memory usage climbing in response to that, although since it dips down after a few minutes I'm not sure what Remedy is doing memory wise.
Edited by Iker
on
Reason: Initial post
It's probably loading & parsing pdb files. UE has a lot of them. When memory usage is increasing try watching file i/o for remedy process, you should see that it's reading them.
Just wanted to chime in that this issue with large pdb's is preventing me from being able to use RemedyBg in my day to day work - it's not just the memory usage but the time, 40-60s, it takes to attach to a UE process.
For smaller projects it's working great, so it's definitely the volume of symbols that's the issue.
Profiling an attach session I can see that a separate thread is spawned to read and process the pdb's - it's spending the majority of the time just reading files. Visual studio loads and processes the same symbols in less than 5 seconds first time.
I wonder if VS is doing some form of lazy loading, as the memory difference between remedybg and VS attached to the same process is 20gb to 200mb.
