Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at id.unity.com during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.


    Read our full announcement for more information and let us know if you have any questions.

Official Improving iteration time on C# script changes

Discussion in 'Scripting' started by xoofx, Oct 18, 2021.

  1. Trindenberg

    Trindenberg

    Joined:
    Dec 3, 2017
    Posts:
    451
    Well I was trying to find out the typical latency of an NVME for accessing a location, apparently it's around 250 microseconds, while a HDD is around 2-4 milliseconds - not 100% if that's correct. So if I calculate that over 10000 random file accesses that's 2.5 seconds (or 20-40 seconds HDD). I did do a Process Monitor on a basic script change a while back, and this had about 100k ops but not sure how many were file location requests. I should try it again and see how many times it's looking for a location. Also not sure if when a process is requesting a dll of the 100/0s in Unity/C# core, whether that means they are loaded into memory/cache when accessed again.

    I always wondered, like hibernate, which stores a state - surely in a script change there is some part of the process that is 'exactly the same' every single time, and yet this is being re-processed. This could be down to C# limitations, but, there must be ways to cheat the system! Smart reload, hot reload for some things ie. user only said x = 2 rather than x = 1, no need to reload everything. Maybe some initial 'mapping' on the first loadup (memory bound), and then when anything is changed in a simple way, mapped function or value points are simply updated. This would also mean being able to hotwire certain parts of code, like values to some kind of interface that is not 'in the code'. The only way to do this otherwise, is to create a mod control script that is coded into the values without needing to edit it directly and recompile (but we don't want to build mods for everything hardcoded).

    I'm sure this is in some way hackable using debug and Visual Studio, but I mean more in a direct non-debug/hacky way. Unity is built in a very hacky modular way which is what is nice about it, but also part of the slowdown as that environment gets bigger. Add smart/fast hacky on top of that, and then it is best of both worlds.
     
  2. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
    It's very dependent on the drive and the task. Most people on HDDs are on them because they either can't afford or don't have the ability to use an SSD. Western Digital Blue drives are fairly affordable with the cheapest being as low as $30 for 1TB. Average latency for them is 8ms. Maximum latency is about 34ms.

    From my limited understanding I believe the average latency is the time to wait for the correct location within the same or an adjacent track to spin under the heads while the maximum latency is the time to move to for example the last track from the first track and then wait for the heads to reach the data.

    When I was still purchasing HDDs I regularly purchased WD Blacks which at the time were the peak consumer drives and average 4K reads were around 0.5MB/sec. By comparison a Samsung 850 EVO (my first SATA SSD) typically hit 50MB/sec.

    https://www.newegg.com/blue-wd10ezex-1tb/p/N82E16822236339
    https://www.storagereview.com/review/western-digital-caviar-blue-1tb-review-wd10ealx

    Just to clarify a bit: the C# compiler is as far as I'm aware single-threaded, but both stages of the IL2CPP build process are multithreaded (IL -> C++ has been that way since 2020.2 and C++ has always been multithreaded).

    https://forum.unity.com/threads/is-compilation-multi-threaded.882592/#post-6611788
     
    Last edited: Feb 24, 2024
    Trindenberg and mahdi_jeddi like this.
  3. davidnibi

    davidnibi

    Joined:
    Dec 19, 2012
    Posts:
    429
    I'll ignore the fact I was offering help and you just gave criticisms and just assumed everything about what I do, but the proof is in the pudding (which is my PC's rating on that PC hardware speed site), and apart from the fan going at 10,000 rpm, my ten year old PC works fine with no compilation problems.
    I have a mix of five 1tb/500gb SSD's that run fine, I never said I had m.2. My 10 year old PC does have an m.2 port though.
    I have a year old Alienware M15 R7 I use for Houdini and Unreal stuff, it's overkill for Unity work, or the work I'm currently working on.
     
  4. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
    I don't have a problem with the majority of your post. I have a problem with statements implying that a decade old computer is fine because we've had entirely too many beginners see statements of that nature and treat it as if it were applicable to every situation and not just someone's personal workload.

    Speaking of personal workloads my current system was built because a Ryzen 5 3600 was taking in excess of two hours to make an HDRP build for a work project targeting the consoles. I can't even imagine what that would have been like on a decade old computer.

    Thankfully there is a middle ground here and you're not limited to just current and outdated PCs. Here are a couple example laptops from a discussion earlier. Both of these are less than half the price ($649 and $781) of your laptop ($1,599) while still punching far above any decade old computer. In fact the second one isn't that far behind yours.

    https://www.amazon.com/MSI-GF63-9SC-068-i5-9300H-GeForce/dp/B07QD32VTT
    https://www.amazon.com/AN515-58-57Y8-i5-12500H-GeForce-Display-Keyboard/dp/B0BSLWGFXD/
     
    Last edited: Feb 26, 2024
  5. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    2,256
    tbh, I had an area 51 threadripper it was 7 years old. for its time it was smokin hot.. it has duel 1080ti's, it has ssd, and 32gb memory..

    last year, i bought a 200quid laptop.. it kept up with it.. there were a few situations it was a few fps behind.. but for the most part, it kept up with it. A seriously cheap no name brand laptop of crapness..

    I never really realised how slow either were till i faced the fact i wanted a pc not a laptop, and bought a new alienware.. Aurora r16 .. daaaymn this thing flys.
     
    Ryiah likes this.
  6. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
    Age is a major factor. A decade old computer that was top-of-the-line won't even be budget tier today and it's why I'm always shaking my head at people who stick to very old hardware when they can afford better. In some parts of the world you'll save more on the cost of electricity than you would have keeping the PC.

    Threadripper is an interesting situation too because the first generation of Zen wasn't terribly great. It had a ton of limitations because the company was essentially pulling a Final Fantasy with their CPU division. Zen 2 is when the CPUs became great but by that point AMD didn't really want to keep Threadripper.
     
    Last edited: Feb 26, 2024
  7. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    2,256
    no, and this was me trying to demonstrate it, on paper it really isnt bad.. cos arguably its not.. but exceptionally few things use sli mode cards, so having 2 1080s is frankly a waste these days. the cpu while many cored and all that, was great back then compared to most, but it wasnt an F1 next to a moped, so as you say, today much as it was a fast car for then, the family average now matches it. So, its good enough for minor game play, at not max quality, internet mooching, show watching, etc.. but not, hard grind and even the 2080 card P's on the pair of 1080s, so, if nothing else, if the machine would take it a faster graphics card would buy a bit more life, but to be honest, not a lot.
     
  8. orvedal

    orvedal

    Joined:
    Nov 10, 2015
    Posts:
    47
    these days = none.
    all time = only a few ever games supported SLI. Impressing people on 3DMark was the only advantage ever.
     
  9. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
    That said there is a potential future depending on if companies decide to integrate LLMs into their games as the software platform that powers them is not only capable of using multiple GPUs but also benefits from it greatly.
     
  10. orvedal

    orvedal

    Joined:
    Nov 10, 2015
    Posts:
    47
    Pretty much everyone will tell you that SLI is dead.
     
    Eclextic likes this.
  11. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
    That's what's great about it. It's not SLI and it's not CrossFire. You simply add the cards and the software that drives the AI automatically uses them. You don't need special hardware support, a bridge between the cards, or even driver support. You don't even technically need a fast slot. PCIe x1 from the chipset is more than sufficient.

    https://assetstore.unity.com/packages/tools/ai-ml-integration/llm-for-unity-273604
     
    angrypenguin, orvedal and DragonCoder like this.
  12. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,789
    The idea of having another card in the PC for a game related purpose already didn't get popular when PhysX was supporting that approach. Can't really imagine that becoming a thing for AI either.
    More likely CPUs will start have integrated AI cores/components in a few generations.
     
    mahdi_jeddi likes this.
  13. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
    Unfortunately, this is the order of priority for AI: memory bandwidth -> memory capacity -> compute. While a CPU can have compute and memory capacity it doesn't really have memory bandwidth. A basic graphics card like the Intel Arc A770 for $280 is >10x the memory bandwidth (560GB for A770 vs 51.2GB for DDR4-3200).

    Once upon a time we had two graphics cards: a 2D card and a 3D accelerator. PhysX is an awful example even if it is a common one as physics is just not heavily utilized in video games. AI has a very good chance of being heavily utilized.
     
    Last edited: Mar 23, 2024
  14. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    2,058
    FYI

    Following tests I discovered the package DevOps-VersionControl (com.unity.collab-proxy ) 2.2.0-Oct 11, 2023 was constantly adding anywhere from 0.5 - 2.5 seconds to the Assembly Reload period of a new project in 2022.3.14f. Unsure why it fluctuated in the extra time it took, however upon removing that package, the project consistently reloaded the assemblies in 2.27 - 2.29 seconds instead of 2.8 - 4.5 seconds!

    Checking the Profiler 'InitialiseOnLoad ToolbarBootstrap' from 'Unity.CollabProxy.Editor.dll' seems to be the biggest culprit, but it alone doesn't account for the entire time. However I noticed that there is also a 'PlasticPlugin' constructor,so clearly we are looking at this package adding several 'InitaliseOnLoad' constructors and maybe causing issues elsewhere in the reload domain process that I missed.

    This might explain the inconsistent results, where there was always an increase in Assembly Reload duration, but sometimes it could be up to 2-3 seconds more than normal! So in one run the profiler might report ToolbarBootstrap as the biggest culprit, but another run might report 'PlasticPlugin' instead ( Edit - I never actually tested this - so speculation on my part)

    I hope Unity are still investigating these issues and not just pinning their hopes on the CoreCLR update that will happen in 2-3 years. Honestly having read this whole thread from the beginning I had hoped that Unity would have actively tested each of the packages or better actively gone through each package and moved code set up out of the constructors called from 'InitlaiseOnLoad', but apparently that has not happened.



    Further details
    The tests were performed with minimal open tabs/windows (Game, Console, Hierarchy, Inspector, Project ) and a recompile/reload domains was forced by right-clicking the same script file and using 'reimport'.

    The project was newly create last week for testing Unity Terrains, using the 'engineering' package. I later removed the 'engineering' package as you can no longer remove individual packages that it references, even after unlocking them. I then installed only the base packages I needed, though that grew as i used the Unity StarterAsset-FirstPersonController asset ( which outside of its demo sample, uses URP for a single material applied to a proxy capsule model!), so ended up with Burst, Cinemachine, Core RP Lib, Input System, Searcher, Shader Graph, URP, URP config etc.

    At no point did I actively install DevOps-VersionControl and I missed it for a long time as I was unaware of the new 'Services' tab in the Package manager. It was only through looking at the actual manifest file that I eventually discovered it was the old 'con.unitycollab-proxy' package, which from memory is like a default package that is always added to a new Unity Project. The issue being that it is added to the new 'Services' tab in the PackageManager, that I'm not used to seeing as I usually work in 2019.4 LTS.


    While I feel this is another package that needs to be looked at and fixed, it probably shouldn't even be added to a default project in the first place.
     
    Last edited: Mar 26, 2024
    stonstad, Eclextic, pKallv and 4 others like this.
  15. KamilCSPS

    KamilCSPS

    Joined:
    May 21, 2020
    Posts:
    455
    Great Find!

    Pinging @carlosalba1985 from the Plastic team for some insight. Any idea if the plugin can be streamlined?
     
    Noisecrime likes this.
  16. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    2,256
    what would be even nicer if all these packages some of us never use werent forced into every new project. Given at one point we were encouraged to make project templates, now apparently its not supported, so we cant even make a project template without them
     
  17. FaithlessOne

    FaithlessOne

    Joined:
    Jun 19, 2017
    Posts:
    330
    I have some numbers to share regarding this. I recently switched from a PC system that was 10 years old to a modern system.

    My old development system had an Intel i5-3570 3.4 GHz with 4 cores, 32 GB of DDR3 RAM with 1600 MHz clock speed, and an SSD with approximately 500 MB/s read/write data transfer and approximately 80,000 IOPS read/write.

    My new development system is an Intel i7-14700 3.4 GHz with 20 cores, 64 GB of DDR5 RAM with 5600 MHz clock speed, and the SSD has approximately 7000 MB/s read and 5000 MB/s write data transfer, and approximately 1 million IOPS read/write.

    The compile and domain reload times of my project on my old system were between 40 and 50 seconds every time I changed the scripts of my project. With the new system, the time dropped significantly to about 15 seconds. The improvements are also affecting other relevant parts, like the frame rate during play mode in the Unity Editor, which increased from 50 FPS to 160 FPS. While an improvement in general is not surprising, a speed up of 3 times makes a huge difference.
     
    mahdi_jeddi and DragonCoder like this.
  18. valarnur

    valarnur

    Joined:
    Apr 7, 2019
    Posts:
    443
    Still compile times should be equal or less than second regardless of system by restructuring and rewriting the API.
     
  19. Eclextic

    Eclextic

    Joined:
    Sep 28, 2020
    Posts:
    143
    Agreed, especially keeping in mind that this was supposed to be a promise from Unity, to keep compile-times unnoticeable (under 0.3 sec I think it was?).
     
  20. valarnur

    valarnur

    Joined:
    Apr 7, 2019
    Posts:
    443
    500ms I think.
     
    mahdi_jeddi and Eclextic like this.
  21. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
    You can hit those speeds with older releases like Unity 5.6.7 so in theory it should be possible now. You're still going to need a good machine to do it though. In my case I was seeing <500ms with a 5950X but with period appropriate hardware the performance was around three seconds if I remember correctly.
     
  22. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,789
    C++ devs: Die of laughter xD
     
    Ryiah likes this.
  23. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,111
    They already about like this most time consumed by domain reload.
    You already can mitigate most of it with Hot Reload Asset store package. Change code Alt+Tab to Unity and you already running on new version of code without exiting play mode.

    Similar functionality must be in new Unity with new .Net out of the box. in .Net land it is called Edit and Continue.
     
  24. RobertOne

    RobertOne

    Joined:
    Feb 5, 2014
    Posts:
    261
    in good old tradition:

    unity 6 b13: Script compilation time:2.915s
     
    ScrepY, mahdi_jeddi and Ryiah like this.
  25. beastxplode

    beastxplode

    Joined:
    Nov 26, 2016
    Posts:
    16
    Fairly new and empty project setup with only 3 scripts, and it takes around a minute every time I either save, create, or delete a CS file. ~40 seconds for AssetDatabase.V2.Refresh to compile, I'm not sure where this is coming from, I don't have any assets imported into the project either. I'm using Unity 2022.3.27f1
     
    Rodolfo-Rubens likes this.
  26. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    8,647
    There's a lot of packages in a new project that can be removed, which greatly speeds up iteration time. For example, most of us don't use Visual Scripting, so remove it. Try slim down all the packages you don't need and see how it improves.
     
  27. beastxplode

    beastxplode

    Joined:
    Nov 26, 2016
    Posts:
    16
    I've removed what little I could except for the ones I need or can't: Addressables, Burst, Code Coverage, Collections, Core RP Library, Editor Coroutines, Entities, Entities Graphics, HDRP, JetBrains Rider Editor, Localization, Mathematics, Netcode for Entities, Newtonsoft Json, Profile Analyzer, Scriptable Build Pipeline, Serialization, Shader Graph, Sysroot Base, Sysroot Linux x64, Test Framework, TextMeshPro, Timeline, Unity Logging, Unity Profiling Core API, Unity Transport, Unity UI, Visual Effect Graph, Visual Studio Code Editor, and Visual Studio Editor

    Most of them are installed as a dependency or as part of the Engineering package. It did reduce it down to ~44 seconds total (from ~58 seconds) which is better but still incredibly slow for actual development. If it's like this now then I'm worried of how much worse it will potentially get as the project grows.

    Is there anyway to disable packages from re-compiling everytime I make edits to the game scripts? I'm a little confused why this is even happening especially since you would expect that the official packages would be pre-compiled into assemblies.
     
  28. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    2,256
    you can remove engineering. Which then removes all the crap .. i hate it defaults to engineering and a big pile it doesnt need
     
  29. spiney199

    spiney199

    Joined:
    Feb 11, 2021
    Posts:
    8,647
    You don't need three different code editor packages (JetBrains Rider, Visual Studio, and Visual Studio Code). Just keep the package for the IDE that you're using, and remove the rest.

    Anyway, only code in the assemblies you have modified, and assemblies dependant on said changes, get recompiled. Meaning packages aren't getting recompiled every domain reload.

    Just that code recompilation isn't the only part of a domain reload. Only a small part of it, in fact. Reducing the sheer amount of files some packages introduce (along with the code) does cut down on a lot of domain reload time.

    What hardware are you running off? Unity is unfortunately very CPU hungry. Perhaps try Unity 6 to see if there is a notable difference.
     
    Ryiah and Spy-Master like this.
  30. Spy-Master

    Spy-Master

    Joined:
    Aug 4, 2022
    Posts:
    908
    Not really. There is a ton of conditional compilation that happens which necessitates packages being compiled from source.
    -Editor-only code
    -Version-specific functionality and bugfixes
    -Collections safety checks
    -Platform-specifics
     
    Ryiah and spiney199 like this.
  31. beastxplode

    beastxplode

    Joined:
    Nov 26, 2016
    Posts:
    16
    Yeah I had to remove it in a different UI screen, it was greyed out in the list when clicking. I'm running on Intel i7-7700k 4.2GHz I'm only noticing these extreme slow compile times on latest LTS version, prior unity versions like 2019 was not as bad as this. I've disabled domain reload as well but still averaging ~50-60s compile time where majority comes from AssetDatabase.Refresh, for simply deleting a file or updating it
     
  32. beastxplode

    beastxplode

    Joined:
    Nov 26, 2016
    Posts:
    16
    Update: Turns out Unity really doesn't like it when you upgrade an existing project to a newer release. Even though the project was fairly empty with only the 3 scripts as mentioned before. I created a new project and copied the files over and now the compile time is much faster, roughly 2 seconds long. I guess that's what I get for being lazy.. removing packages had no effect on compile time and I even have more packages enabled now than the affected project
     
    stonstad, JesOb and spiney199 like this.
  33. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,789
    Did you try deleting the library folder first or Assets->Reimport All Assets?
     
    Rodolfo-Rubens and Eclextic like this.
  34. beastxplode

    beastxplode

    Joined:
    Nov 26, 2016
    Posts:
    16
    No, but that's a good point.. deleting the library folder and re-opening the project does seem to have the same outcome. So defintely good to know for down the road if we ever need to upgrade the major release version.
     
    Eclextic likes this.
  35. DragonCoder

    DragonCoder

    Joined:
    Jul 3, 2015
    Posts:
    1,789
    Wonder why Unity doesn't do the library-clearing automatically by now. It has been a solution quite often and Unity seems to do some lengthy special import anyways whenever you switch the version, so none would complain...
     
  36. Noisecrime

    Noisecrime

    Joined:
    Apr 7, 2010
    Posts:
    2,058
    In older versions (2019.x) I swear you could delete engineering packages, but in newer versions (2022.x) you can’t and have to delete the engineering package itself, which is a right pain when you use 50-70% of the packages included.

    More frustrating is it seems Unity never bothered to support custom user package containers. That would have been perfect as nearly every project I make has a small number of core packages. I followed some guides to make them yourself, but at the time it ended up just braking the editor completely.
     
    Pitou22, Ryiah and Lurking-Ninja like this.
  37. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    2,256
    I made a template for hub i could select that didnt have them, but apparently we arent supposed to do that...
    I also thought previously you could remove things you didnt want... so its not just you
     
  38. Slashbot64

    Slashbot64

    Joined:
    Jun 15, 2020
    Posts:
    377
    Would be good to have benchmarks that we can run to locally compare system disk/cpu/ram performance on unity script compile.. and what setups others have... thinking about upgrading but not sure how much time saving I'd get without any good references.
     
  39. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,208
    Deleting the library did it for me... for the first 2 days, after that it is back taking 40 seconds to compile and 40 seconds to enter play mode without doing any changes to the project.

    Most of the time is for "Importing Assets" (when there is no change to the project files), "GameView.Repaint" and "ProjectBrowser.Repaint". Looking at the stats in the task manager I can't see any spike so what exactly is happening here?

    Also a very small project.
     
  40. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,208
    Same here, and upon looking at the GC allocation for me is 54MB, for your it seems to be 98.6MB... maybe that's normal.

    Also, looking at the Asset Loading session in the profile, there is a list of assets very suspicious, 591 in total and most of it is editor icons, again, maybe it's normal but it's still weird.

    Anyway, will open a ticket using the company's email to get a faster reply on this one.

    edit: after working around this with a restart of the editor I checked the profiler and we get very similar numbers in the profiler so it must be something else.
     
    Last edited: Jun 8, 2024
  41. valarnur

    valarnur

    Joined:
    Apr 7, 2019
    Posts:
    443
    You mean compiling C#script? It should compile it less than a second.
     
  42. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,208
    Just one more thing, just closing and reopening Unity fixes this at least for me, after restarting Unity, around 2 seconds to recompile and the same to enter play mode.

    So yeah, something is incredibly wrong with this Editor version. Or, like someone mentioned, the visual studio being attached to the Editor or something like that.
     
  43. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,208
    Yep, after working for a while, editing scripts, debugging, importing files, moving files around, hitting play, the editor becomes extremely slow for me (recomps and entering play mode), but like I mentioned above, it fixes itself if I restart.

    (this is another one that if unity dog-fooded their engine they would have caught, I can't see a QA working on the same ticket, messing around a project pretending to be working on a dummy project for 2 days to get this reproduced so the Devs could jump in and fix it)
     
    Last edited: Jun 8, 2024
  44. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
    No. It's very unlikely that would be the case as most of the time developers aren't jumping to the latest release of the engine. For example my current work project started with Unity 2023.1.11 and we're still on that release. Unity dog-fooding their engine would help immensely but it won't help with rare bugs, oddities, or regressions that only appear in a small number of releases in a specific situation.
     
    Last edited: Jun 8, 2024
    LooperVFX likes this.
  45. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,208
    Perhaps, but look at the age of this thread:
    https://forum.unity.com/threads/lots-of-busy-hold-on-etc.833644/

    This has been around for some time now.

    And btw: We work on a project that was released in 2018 and we updated a couple of times already and planning to update to the latest LTS, we have some complaints from some engineers (mostly on Windows or intel macs) having this same issue already in the 2021.3 version.
     
  46. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
    I'm aware there were similar problems but they're not likely the same source and from the looks of it the problem in that thread was identified and fixed.

    Hopefully it's not happening in whichever version you finally settle down on.
     
  47. Rodolfo-Rubens

    Rodolfo-Rubens

    Joined:
    Nov 17, 2012
    Posts:
    1,208
    Also this one: https://forum.unity.com/threads/getting-stuck-on-domain-reload.1377126/page-3
    Which is up to date.

    Maybe, but it's not rare to see someone having this popup lingering there locking the editor (despite the reason). Every client retrospective at the company someone brings this up.
     
    Ryiah likes this.
  48. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    21,937
  49. Lo-renzo

    Lo-renzo

    Joined:
    Apr 8, 2018
    Posts:
    1,533
    Whyyyyy.... Similar problem - I just wanted to remove some 2D packages but keep ONE and it's forced me to reimport all my sprites too. There goes half an hour.
     
    bugfinders likes this.
  50. Sandler

    Sandler

    Joined:
    Nov 6, 2015
    Posts:
    249
    I may found a small optimization ->

    Issue:
    You compile your code a domain reload happens, you enter play mode a domain reload happens. You do the same thing twice.

    With this code you can press ctrl-d and directly enter the play mode without domain reload, it resets afterwards. So at least you do not need a second domain reload Tested in 2022 LTS. Probably halves the time from compile to play mode. You can press it while you see the compile message

    Edit: im seriously questioning if something like that was never thought of, or if im overlooking something. Feels like that could save a few people 1 day of waittime in a year. If this is logical please unity make it build in or an option to not domain unload on first entry after compile

    Edit2: if someone is interested PM me, i just wrote a visual studio / visual commander plugin that saves all changes, focuses unity and sends the ctrl-d command to it. halves the time needed to go into playmode. windows only

    Code (CSharp):
    1.  
    2. [MenuItem("Tools/Reload Domain and Enter Play Mode %d")]
    3.     public static void ReloadDomainAndEnterPlayMode() {
    4.         if (EditorApplication.isPlaying) {
    5.             Debug.LogWarning("Cannot reload the domain while in Play Mode.");
    6.             return;
    7.         }
    8.    
    9.         EditorSettings.enterPlayModeOptionsEnabled = true;
    10.         EditorSettings.enterPlayModeOptions = EnterPlayModeOptions.DisableDomainReload;
    11.         EditorApplication.playModeStateChanged += ResetPlayModeOptions;
    12.         System.Threading.Thread.Sleep(100);
    13.         // Enter Play Mode
    14.         EditorApplication.EnterPlaymode();
    15.         Debug.Log("Entered Play Mode.");
    16.     }
    17.     private static void ResetPlayModeOptions(PlayModeStateChange state) {
    18.         // Check if play mode has just been exited
    19.         if (state == PlayModeStateChange.EnteredPlayMode) {
    20.             // Reset the play mode options to default
    21.             EditorSettings.enterPlayModeOptionsEnabled = false;
    22.             EditorSettings.enterPlayModeOptions = EnterPlayModeOptions.None;
    23.             Debug.Log("Entered Play Mode and disabled playmode options again");
    24.             // Remove the listener to prevent it from running multiple times
    25.             EditorApplication.playModeStateChanged -= ResetPlayModeOptions;
    26.         }
    27.     }
     
    Last edited: Jun 12, 2024
    Eclextic likes this.