ResharperC++ crashes VS2017 when trying to parse UE sources
Trying to make Re# C++ to parse UE sources and failed like 10 times on two different PC. I have a feeling that it runs out of memory and VS2017 crashes, but I also can be wrong. Half of the sources (according to progress bar) is parsed fairly ok. I can see that VS2017 process writes and reads 2-3Mb/s and when it reaches 2/3 it writes like 0.1Mb/s and makes VS2017 extremely choppy. I can understand that parsing such a huge code base takes some time but why blocking VS2017 editor? You probably need to update some db in ui thread but can't you do it when you have all the data and make sure it's quick? After 30mins its impossible to type anything.
I think half a year ago it worked much better. At least I don't remember having such negative experience. Yes it was slow, but eventually it was ok. It's quite weird that VS can compile whole UE much faster than ReSharper can index (and with latest versions it can't even index it).
Please sign in to leave a comment.
Hello Sergiy,
We've improved performance in UE4 solutions a lot in 2019.1. Initial indexing of the engine should now take 4-5 minutes, and memory consumption afterwards should be better. We plan to open 2019.1 EAP next week, would appreciate if you could try it. I'll ping this thread when a build is available.
If you'd still like to try 2018.3, I suggest excluding the engine code from indexing in "Third-Party Code" (https://www.jetbrains.com/help/resharper/Reference_Options_Code_Editing_Third_Party_Code.html). The headers that you use from the engine in your game will still get parsed.
Wow, that's impressive. Can't wait to try it. Thanks.
With 2018.3 I tried "Third Party Code" for some non important parts like libs but it didn't help. When it gets to last 25% it becomes unresponsive. Also I can see few:
60 413209.382796 21784 devenv.exe E| --LOGLOG-- | <unnamed-thread>:52 | System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
61 413209.382796 21784 devenv.exe at System.String.ReplaceInternal(String oldValue, String newValue)
62 413209.382796 21784 devenv.exe at System.String.Replace(String oldValue, String newValue)
63 413209.382796 21784 devenv.exe at JetBrains.Util.ExceptionRenderer.PrintExDatas(IList`1 arExceptionsUnsorted)
64 413209.382796 21784 devenv.exe at JetBrains.Util.ExceptionRenderer.<>c__DisplayClass9_1.<RenderException>b__1()
65 413209.382796 21784 devenv.exe at JetBrains.Util.ExceptionRenderer.GetExceptionDataCached(Exception ex, String key, Func`1 FProduce)
66 413209.382796 21784 devenv.exe at JetBrains.Util.ExceptionRenderer.RenderException(Exception ex, IDictionary`2 customData, Nullable`1 renderSensitiveData)
67 413209.382796 21784 devenv.exe at JetBrains.Util.LogEvent.get_FullExceptionTextWithSensitiveData()
68 413209.382796 21784 devenv.exe at JetBrains.Util.Logging.PatternLayout.<>c.<.ctor>b__15_4(LogEvent le)
69 413209.382796 21784 devenv.exe at JetBrains.Util.Logging.PatternLayout.FuncPartProducer.Format(UnsafeWriter writer, LogEvent logEvent)
70 413209.382796 21784 devenv.exe at JetBrains.Util.Logging.PatternLayout.FormatUnsafe(UnsafeWriter writer, LogEvent logEvent)
71 413209.382796 21784 devenv.exe at JetBrains.Util.Logging.SimpleLayout.FormatUnsafe(UnsafeWriter writer, LogEvent logEvent)
72 413209.382796 21784 devenv.exe at JetBrains.Util.AsyncLogEventListener.WriteLogEvent(UnsafeWriter writer, LogEvent logEvent)
73 413209.382796 21784 devenv.exe at JetBrains.Util.AsyncLogEventListener.OnLogEvent(LogEvent logEvent)
74 413209.382796 21784 devenv.exe at JetBrains.Util.Logging.ConfiguredLogger.Log(LogEvent logEvent)
Could you please check that you are using 2018.3.2 or later? There was an OOM issue fixed in that build.
It's 2018.3.3.
If you have time, a memory snapshot would be helpful - attach with dotMemory when Visual Studio gets unresponsive because of memory problems, collect a snapshot and send it to us (https://intellij-support.jetbrains.com/hc/en-us/articles/206869619-Uploading-Large-Files-for-JetBrains-Support-Team).
I suggest waiting for a 2019.1 build or you can exclude the entire UE4 folder from indexing for now (it shouldn't really affect user experience much except for auto- import and navigating to a symbol from a header which is not included into your project yet).
I couldn't use built-in profile tool and used dotMemory as you suggested.
visual studio restarted, but I don't know the reason. there are no crashdumps, it just closed itself and started a new instance. There is probably no need to look at the snapshot, they look ok. for 40 minutes it was able to work well. I wasn't editing code though, so don't know if it was sluggish.
Unfortunately I can't exclude UE source code from indexing, since I'm working on part of it, so I will wait for EAP. Would be great if it works.
[update] actually VS didn't crash after it was done with parsing. I was mistaken. Re# was done indexing UE sources and I started typing and it became slower and slower until VS got frozen and restarted itself. Unfortunately I already closed dotMemory at that time.
[update] after VS restarted, Re# was able to load index this time and didn't rebuild it. That ended fairly quickly and now it seems to work. It hangs from time to time when I type but that's quite normal with Re# I guess. At least it happens on other project too.
Sorry for the long wait, 2019.1 EAP is now open - https://www.jetbrains.com/resharper/eap/. https://blog.jetbrains.com/rscpp/resharper-cpp-2019-1-eap-meets-ue4/ has some details. Please ping us if you still see performance problems with UE4 or have feature requests.
You might also want to turn off clang-tidy. It's on by default and runs in an external process, but clang-tidy is very slow on UE4 source files, so if you don't see much use in it it's better to just turn it off.
Since you are working on a part of the engine please note that we've excluded plugins and third-party code in the engine from indexing by default, if you need them you can turn indexing back on in the options:
Thanks, I just installed it. It's amazing. I think it started indexing from scratch and completed it in may be 3 minutes. And parser was very active, utilizing half of the cores and writing sometimes 40mb/s. It also didn't crash, and editor seems to work ok so far. Thanks!