Maybe! I’ve never actually seen compile time that low for hot reload. In my current project if I remove iTween, my compile time is around 24 seconds just adding a new function to my class.
With iTween added as a C++ class family, adding a function to a class unrelated to iTween with no includes takes around 26 seconds, which makes sense as the project is bigger with iTween added of course.
If I include iTween in this class but do not call any iTween functions and add another simple function, compile time is about 51 seconds - a stark change. This does not ever get reduced.
If i take the last scenario and add a call to an iTween function by c++, times are similar.
Adding a function to another class unrelated to iTween other than including the last class sees compile times reduced once again.
To be honest, I’m not completely sure why this happens. I don’t have much insight into the unreal engine compile process. Using the information I found above, the inference I can make regarding this issue is that you are including iTween in one of your C++ classes. Unless it is 100% necessary, I’d remove the include and stick to calling iTween from blueprints making use of inheritance and virtual functions as needed to avoid calling it in C++.
If you must call via C++, I’d put the calls in a separate class and reference it with the class you’re making a lot of incremental changes to. For example, MyGameCharacter.h should NOT include iTween.h, but instead another class MyTweenerClass.h that itself includes iTween.h. Make the calls to iTween from this class. It’ll still take a longer time to compile MyTweenerClass, but in case you’re making many more changes to MyGameCharacter than MyTweenerClass, this should keep compile times down in the long run. Again, it’s fastest to do it all in Blueprint if you can manage that.
My best guess is that the iTween/iTweenEvent classes are so large. I may be able to mitigate this by splitting these classes up into smaller classes, but I’m wary of doing so - it would be a huge timesink and may actually break existing projects - something I’m not keen on doing again. Maybe I can explore the possibility on my next long flight
For reference, the processor on which I tested runs at 2.6 GHz stock, 3.2 under load, 4-core i7 with hyperthreading turned off.
Hey, just as a followup to this in case anyone runs into a similar issue; I never solved the slow compile times so I gave up on the C++ version and I’m using only BPs, but the failure to find the itween scripts on the BP side of things was solved by changing “LoadingPhase”:“Default” to “PreDefault” in my .uplugin file.