Do HeaderAttributes in UnityScript/C# scripts affect performance?

https://docs.unity3d.com/ScriptReference/HeaderAttribute.html

I just discovered these - they are very cool. it's great for cleaning up scripts.

But if i use a lot of them, will they affect performance after compiling? Im mostly on mobile platforms.

 

not really... if they're not accessed at runtime, they're not really doing anything. If I recall correctly, the attribute itself isn't even instantiated unless reflected out.

 

Thank you Im on mobile so every iota of performance counts. Im going to go ahead and use them - they seem very useful and i have always wanted to organize the inspector scripts.

"the attribute itself isn't even instantiated..."
Im curious what this means - i googled "unity instantiating attributes " but didnt find anything. Does this mean that part ofthe scriot isnt included in the compiled binary?

"unless reflected out"
i ave heard of reflection but i dont understand it. Does that only happen in c#? My game is mostly UnityScript, but i am converting my scripts one by one into c# because i get the feeling Unity will drop support for UnityScript (i hope they dont because its a great way for HTML5 game and web designers like me to get into Unity in the first place) and i have heard that c3 is faster, but i dont know if thats true.

I am guessing what all this means is that in a regular script thw HeaderAttribute just isnt included in the compiled code.

Thank you very much

 

No, they do not. Attributes exist at the class-level and can only be accessed via reflection, so unless you have reflection code in your game that looks through attributes on fields (and honestly that'll be real rare) then they're completely free. You should 100% use HeaderAttribute, TooltipAttribute and similar attributes to clean up your behaviours.

But as always, don't guess. Use the profiler and use it on target, not in the editor. Even things you think would matter just don't most of the time. I know people who cache the transform component instead of using the transform property, or avoid using transform.position and use transform.localPosition because position will involve a few extra matrix multiplications. 99.9% of the time these little things will never matter even on mobile and the profiler is what tells you what matters. So do things in the most sensible, easy ways and profile your code. If and when you see a problem, then optimize.

Reflection is an API for querying mono about types and values. You can iterate over a list of fields on any object, for example. It's how the inspector works, that and serialization (which also uses reflection). However, reflection is very rare in your actual game code as it can be quite slow. Also, you probably shouldn't use UnityScript. It's a second-class citizen in the Unity world and should probably be phased out. I'm pretty sure C# is an objectively better choice. But if UnityScript is working for you now you should probably stay put, something to think about for your next project.

I think that was the intent. However, learning C# is not hard. If that's all that's keeping you from Unity if UnityScript weren't there then I don't know what to say.

I'm not sure what this has to do with your previous statement, but I have a feeling it will be faster for smaller games. Construct is natively HTML5, Unity compiles to HTML5 through a very long road and produces very bloated programs in comparison to something natively HTML5. I suspect (but haven't tested) that Construct is much faster for smaller games, that it will load faster and have a more consistent framerate. However I also suspect that Unity will scale to larger games more easily even on HTML5. And now that Webassembly is here, Unity can compile to near native speed wasm where a Javascript engine like Construct is stuck on slower Javascript. So this really depends on the game, but in general Construct will probably be better for smaller HTML5 games.

Back to the subject at hand I guess, yes, it is included in the compiled code. However, as I said, it's part of the type information and has no effect on any particular instance of the script. You could have 5,000 of these sprinkled throughout your code and it won't run any more slowly.

 

Wow - thanks! There's a lot of helpful advice to chew on here. My game is at version 7 and i am focusing on optimization, so this all helps.

I do this, but i guess you mean it's just as fast to use something like:
myGameObject.transform = transform;
if im refrencing the transform my scriot is attached to, i dont need to cache it in the Awake?

For the C3 that was a typo - sorry about that - i meant c#, but now i know about C3

That helps about reflection - it seems like something esoteric - im not going to worry about it

I think you are right. I found this webpage that converts scripts:
http://www.m2h.nl/files/js_to_c.php

It isn't perfect, but i figure i will start converting my scripts, the small ones first, one at a time. Im in no rush to leave UnityScript, but it cant hurt, and i have noticed that c# scriots seem to compile MANY times faster than changes to my UnityScript scripts, although that may be because i have only a handle of c# scripts, and a few hundred UnityScripts in my project

Its just because all of us have different skillsets. So when i was looking for a 3d engine, and not knowing much about it, the fact that i already knew javascript helped seal the deal. I suspect that ease of use has introduced a lot of people to unity, even if c# is a more efficient programming language. Also c# structure seems to be keyed towards the programmers mind - its very logical and the way you write it it seems less likely to make a mess or mistakes, whereas UnityScript is more messy, but for an artists mind like mine which is very visual, the patterns that it makes are something im more comfortable with. that wont stop me from trying to learn c# though, but it will be from necessity for performance, not because i have a string desire or time to learn it.

Thank you - I will - i'm a designer and i love to simplify things, and i live a materialistically minimal life as well. I'm taking an object oriented approach to my scripting and simplifying them is a big part of my process right now. As a neophyte i made complex scripts, but ive come to learn its better to build complexity from smaller components, than to have one large complex blob. It's kind of like DNA - you can get an incredibly complex system from just a few components.

Thank you so much

BTW here is a pic from what i am working on - i couldn't make any games without people like you and lordofduct helping me on the internet - you can make so many more things together than alone:

 

Your process here is really important. Optimizing can be very difficult and choosing random things to try to make faster is not a good way to go about it. It's likely that many of those things, as I mentioned before, don't effect performance at all. All optimizations must start and end in the profiler. Find something that's taking the most amount of time and find a way to make it take less time. Start with the big targets first, your slowest script or your thing that takes the most time to render, and try to make it faster.

Most people try to go at this at random and honestly it never ends well.

 

Thank you - i am using the profiler and am cutting down all the garbage and ms i can find - it seemed complicated at first, but the more i use it, the more i am understanding it.