Mad Compile Time Optimizer - Speed up your development!

Oh wow! I will try it myself on Monday when I will get back from vacations. Internet connection here is just horrible Please let me know if you will find out anything!

@Arkade Hah, that's just my luck Thanks anyway! But maybe the problem is already solved! Fingers crossed!

 

Bad news. Downloaded p8 today and it still seems to be broken :/

 

Well, that's weird ; https://medium.com/@darrentsung/the...compile-time-in-unity-45d1f200572b#.sm91uckiu

 

The bug that's supposedly in 5.3.5p7 is issue ID 804864 -- I see it says it's fixed in 5.3.7. I assume 5.3.5p7 fixes should also be in 5.3.5p8 so that means a failed fix.
Do you think (a) there's merit in our feeding-back in that bug (suggesting it doesn't seem fixed in p7) or (b) logging another bug referencing that one? (I'm not sure which would get better attention -- in some systems a closed, not-re-opened bug's updates aren't seen/prioritized.)

 

I'm really not sure.
I've tried to find an issue in MMC, but it seems like MMC is working fine and this bug is still present in Unity.

I've got an response from Unity that the best would be to submit another bug request for the newest patch version available and give this link telling this is a regression.

 

Hi all!
I have really good news!

Unity 5.4 has fixed the way MCTO is working There should be no more issues.

I said that the bug is still there after p7 patch, but most probably it was gone and I was testing it with scenario that made Unity recompile all the files.

So... MCTO will reduce your compile times whenever you will modify your scripts, but Unity will force recompilation of the whole project whenever you will add, remove or rename a script. It seems that it cannot be helped, but it's not as bad as it could be.

I will still report this as a bug because imo this is something that Unity shouldn't do.

Cheers!

 

Hi, I just bought your asset and so far most of it has been working smoothly.

I want to report a few issues I have had:

When I select only specific folders to optimize, not the whole root folder of a 3rd party asset, your tool moves the folders to the "Plugin" folder directly. Let me give you an example:

What should be happening when I optimize folders "Folder1" and "Folder2" inside a root folder "AssetFolderToOptimize":

Plugins

AssetFolderToOptimize

Folder1
Folder2
​

What happens instead is this:

Plugins

Folder1
Folder2
​

This causes the Plugins folder to become sort of a mess very quickly: Sometimes I had to move only selected folders because otherwise the 3rd party Asset would break (e.g. when I would move Editor scripts to Plugins folder)

Alright, so the second issue I have been having is this exception whenever I test the game in the editor:

IOException: Sharing violation on path C:\Users\kbm\Documents\wunderdoktor\Assets\Mad Compile Time Optimizer\Editor\Resources\TextMesh Pro-log.asset
System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.IO/FileStream.cs:320)
System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share)
(wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
System.IO.File.Open (System.String path, FileMode mode) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.IO/File.cs:347)
MadCompileTimeOptimizer.Upgrade.IsBinaryFile (System.String file)
MadCompileTimeOptimizer.Upgrade.DoUpgrade ()
UnityEditor.EditorApplication.Internal_CallDelayFunctions () (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorApplicationBindings.gen.cs:232)

I have tried reverting the TextMeshPro asset and optimizing it again.. I have tested if the TextMesh Pro.asset file is read-only somehow but it wasn't.. I don't really understand what this means but I hope you can make sense of this somehow.

Thank you very much for your otherwise AWESOME plugin, it has reduced my compile times from 18s to 6.5s already and I'm looking forward to working with it for a long time to come!

 

Hi @kbm
I'm happy to hear that you're satisfied with my product

If you choose to optimize individual assets, it will work as you pointed out.
I can actually add an option to store optimized assets in some kind of subdirectory in Plugins, but I can do that only for non-editor scripts. All editor scripts should be placed in Plugins/Editor. That's some kind of wired limitation and it was the reason why I've created MCTO. I was just tired of moving all the subdirectories by myself.

About Sharing violation on path exception. It happens when you don't have the rights to the asset file. Do you use perforce or anything else that made the file read-only? Do you use the latest MCTO version? Please send me an email to support@madpixelmachine.com, I will send you the latest beta.

Cheers!
Piotr

 

Hello, just bought this addon today . I want to report very annoying bug. The root checkbox is selected but it doesn't effect child boxes.

 

And revert is broken too I think...



There should be Hierarchy.. because as you can see, it's confusing.

 

I'm sorry, I was absent last few days...
Wow, how that happened?!

How to reproduce that? What Unity version are you using?

Piotr

 

5.5.03f

Also I use SourceTree (GIT but with GUI).

 

Ok I think I may know why this is happening.
Have you selected all the child directories too? It seems like it.

It's not a bug that children directories are not checked. It's more like something I missed to indicate. If you select the parent directory, all the children will get optimized too. Yet it's a bug that it allows you to select it, after then things are going crazy

I will secure it to disallow this kind of scenario. Thanks for reporting it!

 

Thanks, it will help future customers too.

Tell me when it is updated so we update, thanks .

 

Sure!

 

Hi @genail

Any update soon? It's almost 2 years without new update and features.

 

Hi,
I did not update it because there was no need of it. Studio-Techtrics asked me to improve one thing that may cause trouble so this will be first update after a long time. Do you have any troubles with the new version?

 

Purchased this plugin to use it with Unity 5.5.3 on macOS, but can't even find the tool menu any advice?

 

Hello,
If you don't see it then most probably you have compile errors in your project. Do you see any errors in your console? If not, please try restarting Unity.

 

Hey, I'm just a dumb patronising attempt to help but could you clarify whether ”can't even find” means you (a) ”know where to look and don't see”, (b) ”don't know where to look and couldn't find” or (c) something else?

 

That fixed it, thanks!

 

Hello genail,

This is a very convenient plugin, and well needed since our compilation time has skyrocketed to over 40s due to copious third party asset packages. One issue, though:

I optimized "Asset Store Packages", which included a lot of subfolders from different providers. This worked well. Then I installed a new package in that folder. When I tried to optimize that, "Asset Store Packages" was still showing as "optimized", even though there were new scripts inside it to optimize. The only way forward that I could find was to revert the whole "Asset Store Packages" folder and re-optimize it (this time on a subfolder by subfolder basis).

Edit: I'm glad you discovered, and shared with us, that the optimization won't work if I rename, add, or remove scripts. I was going crazy because this seemed to work so sporatically. I've been adding, renaming, and removing a lot of little scripts. Hopefully once I stop doing that it'll all compile quicker again. Simple test cases do seem to compile fast, but if you're aware of any other limitations to the optimization, I'd be interested to know.

Edit2: My compilation time is still 14s, even though everything but my own, recent scripts are outside the Plugins folder. On their own in a clean project they only take about 3s to compile. (I changed them to remove the references to the scripts in the Plugins folder, but that affects only a few scripts.) Do you have any idea what could cause this? Is it just because my regular project is so big and takes a lot more memory?

 

Hello TommiH,
I'm glad to know that you're happy with my plugin I've created it for my own reasons - my project's compilation time was also something near 40-50 seconds. Moving assets to Plugins and Standard Assets did the work, but broke all custom inspectors. In the end I had to create a script that was moving all the things for me.

Even if only a small set of scripts is re-compiling, mono compiler still needs to go through already compiled assemblies and do something similar to linking (I don't know the definition though). There's a chance that this is causing your scripts to take more time to compile. Still I'm not certain about it. Unity shares only a little information of how script compilation time can be optimized and what is causing the delay.

As I recommendation I would suggest doing something completely outside of Unity. Are you using anti-virus software by any chance? If yes, make sure to opt out Unity directories from your AV along with your project directories. AV software scans any DLL prior launching, so it has additional work to do every time you change something inside your scripts.

Do you keep your unity projects on HDD instead of SSD? If yes, I'd like to recommend PrimoCache. I'm using it 2-3 years now and it greatly improved my OS performance. I have 2 GB of RAM dedicated to IO cache, so if I'm working on a Unity project, it rarely need to read anything from HDD. It can also use SSD partition to make any HDD in your system to behave like a hybrid drive.

Hope that helps!
Piotr

 

Thanks for the tips genail!

The antivirus is not a problem (I'm on a Mac) but I do use an HDD to store my files. I'll look into PrimoCache.

 

1. I found this open source project to speed up compile progress, check it out
https://github.com/SaladLab/Unity3D.IncrementalCompiler

2. MCTO can not handle dependencies and integration very well. Do you have any plan to upgrade this asset, say adding an ignore list or speed up the revert progress?

 

Hi!

1. Oh that's sweet! I have to try that for my projects too!
2. How do you think that ignore list should be working? Unfortunately reverting speed is something determined by Unity itself. I've tried many different things, but that's the correct way of moving those assets. For some reason Unity takes a really long time when assets are moved from Plugins to Assets/ and I cannot do it by simply copying it because it fails on some Unity versions.

Piotr

 

I thought there could be a whitelist for users to tell them what assets are safe to move. But things are complicated in real life scenario. Say users may want to make custom integration for assets, then neither of them should be moved to /Plugins. So I doubt if there's anything we can do before Unity makes some changes.

 

Hey. Long time!
Just noticed Script Compilation Assembly Definition Files in 2017 beta notes. Thought you'd want to investigate compatability, etc.
HTH

 

@genail I really question the need for this asset ("Mad") and I wonder if you are (unintentionally) misleading game devs by continuing to promote it. You originally created "Mad" because of a bug in Unity prior to 5.4, that has now been fixed for a long time.

Since the script compile issue was fixed long ago in Unity 5.4, I fail to see the need for this asset ("Mad Compile Time Optimizer"). Furthermore, moving misc pieces of assets (scattering them) into either the Plugins folder or Standard Assets seems to be a bad idea, since that is not the purpose of those folders. I know you worked a long time on "Mad" and it is a part of your life and personal legacy, but that does not justify the existence of "Mad" if it's not necessary or if it forces disorganization on the folder structure.

I just feel like you are misleading Unity devs who don't know better, in regards to the need for your asset, and in the process forcing changes on their folder structure which will potentially break their project in the long run, or at least make it difficult to manage their various assets and scripts. The conventional wisdom is to keep various store assets together as much as possible.

For projects without "Mad", I have seen no evidence in the last year that the compile time of scripts is slowing down projects.

In addition, the "update asset" feature in Unity will break if assets split into pieces and scattered around the folder structure.

The "Plugins" folder is meant for DLLs, and "Standard Assets" is meant for Unity assets.

I would appreciate it if you would explain why this asset is needed now that the compile issues were fixed long ago? Thanks.

 

That "some reason" is because any change in the Plugins folder forces a complete recompile of the Plugins .dll, which is time-consuming.

 

Agreed that this plugin is not really needed now. You can easily move assets there yourself by dragging the folder into Plugins. Then taking any editor scripts folder into Plugins/editor new folder named the same as the asset. However, "Mad" does make things easier for those without know how. If you want to upgrade plugin that was moved around, you need to first put it back where it was and there's a window in Mad for that. Then upgrade and re-Mad it back to Plugins folder.

Also, it is a misconception that plugins folder is only for dlls. Read this thread for why. https://forum.unity.com/threads/whe...-scripting-packages-editor-extensions.292674/

But most people are unaware of this so you're not alone. And even if it "isn't proper" to put non-DLL's there, it can insanely help compile time, which is paramount and trumps any "proper" or "non-proper" designations ultimately. We're talking compile time of 2 minutes getting cut down to 20 seconds. I've seen it happen using "Mad" or doing it myself by moving folders.

 

That's interesting. I like the idea of storing folders there temporarily until final builds.

At least in the "Plugins" folder, because the editor folders do not allow any use of outside scripts.

But my first inclination would be to test it myself and see what compile time comparisons are like in 2018.

But I would never let an editor extension (like Mad) rip up the folder structure, especially if I'm considering that the app might be successful and need to scale, or have other people working on it one day.

Thanks for answering my question.

 

Not sure what you mean here. You can use Plugins/Editor and store editor scripts there just like Assets/Editor. Anything else, probably not.

 

"Note: Unity does not allow components derived from MonoBehaviour to be assigned to GameObjects if the scripts are in the Editor folder."

https://docs.unity3d.com/Manual/SpecialFolders.html

As you say, the Editor folder has a specific focus.

This asset (discussed on this thread) is a hack because the Plugins folder has a specific use that is defined by Unity, and you're (i.e. the asset is) hijacking that use. It is a useful hack to drag entire asset folders into the Plugin folder, if it actually increases compile time (I've not tested it myself). But don't expect it to be safe, or consistent. It's a hack that is not endorsed by Unity and they could tighten the focus of the Plugins folder at any time.

And like I said, in regards to this asset discussed in this thread, I would never let some hacker asset dev take my folder structure and split it all up into pieces. That's insane and IMO a professional game dev would never use this asset if they expect to take their project to market in one piece and stable.

 

Ahoy,

Just throwing my two cents here.

First of all, when you develop a game you will also develop tons of Editor scripts/stuff (usually the more complex the game, the more complex the editor side). I'm not sure I understand what the problem with the Editor folder is in this thread, but it's a very important folder and it doesn't have to be in the root of the project: it works wherever you put it, even if you have multiples. Monobehaviours won't work from within it simply because builds will not include anything that's inside an Editor folder: it's just for Unity's editor stuff.

About the Plugins folder, I wouldn't say it's a hack because it's so widely used that it's now a convention. Every big (or small) project I worked on, regardless of the size of the team, uses/d it. Because yes, it does shorten compilation time dramatically. Anything inside the Plugins folder (as well as anything inside the Standard Assets folder) is recompiled ONLY if one of its files change, otherwise it stays untouched. It's a cool folder to use

About MCTO, I personally don't use it, though I loved the idea. But I'm sure it can be useful, since its logic still makes sense and there's still some asset that doesn't work well when moved completely inside the Plugins folder. If it's not for you it's ok, but I'd say that's all there is.

 

Adding to what Izitmee said, which was all correct.

The "official Unity" page on Special Folders has not been updated in many years, and many consider it to be incorrect. Specfically the part about only putting DLL's in that folder (obviously Android puts jar files there and are pretty similar to a DLL so we'll let that slide).

It's not a "hack" to put non-compiled code in the plugins folder. The newest version of Unity will actually even allow you to put .java class files in Plugins/Android and will create the jar file for you. More info here: https://forum.unity.com/threads/java-source-files-as-plugins.536292/

Unity has always supported having source code in the Plugins folder, and the bottom line is that it's for code "that doesn't change" - such as every single plugin you bought from the Asset Store that contains code. Why should you have to compile all that every time you change your actual game code? It's a terrible waste of time and gets worse with every plugin you install and don't place in the Plugins folder. It's definitely for sure that it will compile faster. Will illustrate why now. Plugins is a separate csproj file that compiles separately and only if a source code file in Plugins has changed. On the page you linked, the order of project files that compile is shown, pasted here for reference:


Phase 1: Runtime scripts in folders called Standard Assets, Pro Standard Assets and Plugins.
Phase 2: Editor scripts in folders called Editor that are anywhere inside top-level folders called Standard Assets, Pro Standard Assets and Plugins.
Phase 3: All other scripts that are not inside a folder called Editor.
Phase 4: All remaining scripts (those that are inside a folder called Editor).

----
Notice that phase 1 mentions "scripts in Plugins". Why would it even mention compilation if you could only have DLL's? DLL's are already compiled and Unity will not process them. And no, this was not added to this page during the last release when .java class support was added. It was always there. So basically it mentioning the Plugins folder in an order of compilation discussion means they support source code files there. This will not just randomly change at any point in the future.

Again, the best places to put your code for assets is outlined here:
https://forum.unity.com/threads/whe...-scripting-packages-editor-extensions.292674/
He advocates using the Plugins folder. I agree.​

 

The Plugins official documentation does not support what you are saying, but I understand that it's being done a lot, and it's useful, so it's a useful hack, for now.

Unity admin should change the documentation to say that the Plugins folder is for this purpose. Otherwise, it would be great to have another folder specifically for what you are saying: to drag assets not being used, so they don't compile. I have that issue all the time.

Thank you for sharing though, I'm gonna try it.

And like I said, if you trust a 3rd party asset, you're putting the life of your project into someone else's hands. As some comments from people who have purchased the asset this year (Mad Compile Time Organizer) have said: "...new Unity Assembly Definition Files make this obsolete." And: "Perhaps this worked in the past; but does not appear to anymore." And: "If you try to revert that you'll create even bigger mess."

My purpose is not to criticize, but this asset seems obsolete and for it to be still promoted seems irresponsible. But beyond that, I've got to create a tutorial video today on Unity folder structure best practices, so I'm trying to really get into the details, so thanks again for the comments and discussion.

 

@jerotas So the Plugins folder content does not compile again unless it is changed? Is that correct?

 

Actually it does, although indirectly. Read my post right after his.

 

Unless a source code file changes, that's correct. That's why it's for "code that doesn't change". Now you go changing your code in Standard Assets where your game code will live and never again (until you add / upgrade a new asset) need to recompile Plugins folder. Really cool and invaluable to the programmers in your group. Can make an unusable computer usable again because of compile time concerns.

 

@jerotas I'm doing a video review of Master Audio by the way. Great asset. (sorry, off-topic)

 

Don't want to derail this thread. Contact me with any questions or concerns

 

@jerotas Standard Assets is intended for Unity Standard Assets. Why put anything else there? Keeping a large project organized is difficult anyway without breaking the conventions that Unity have. Except for the Plugins folder, he he.

 

I think I said a wrong folder name. I meant "any folder that's compiled after Plugins", wherever you want to put them

 

@jerotas That's an epic realization; thanks. I know what you mean, my Unity IDE croaks every time I save a script. I like to put my final game files in a folder "_NameOfGame" and the unused asset store assets in a folder "3rdParty" but now I see that (at some point) both these folders should then be dragged to the Plugins folder. Awesome stuff.

**worships at Altar of Jerotas and Izitmee**

 

Glad to be of service. Wasted time is the worst! We only have so much time right? I learned from that thread that I posted a few posts up. I had no idea before. Just passing on what I learned from others

It's a double drag though. Editor scripts have a slightly different structure in Plugins so you'll have to move those after moving everything to Plugins if you have Editor scripts for each plugin.