What is the most efficient way to initialize an instance?

[KristinaMoment (Kristina)]

Initializing - Setting properties to stuff

So for instance, I have this section of code in a script, which is setting up a TextLabel, parenting it to a BillboardGui in the Instance.new() as a parameter, then setting up each property as usual.

Is there any better way to initialize an Instance? Particularly more efficient ones.

[DasKairo (Cairo)]

This should already be efficient, but to make it more efficient, its recommended that you do not use the 2nd argument in Instance.new() due to performance.

[ValtryekRBLX (Nexus)]

Why not just place it in StarterGui and make it invisible, then move it over when you need to?

[KristinaMoment (Kristina)]

@DasKairo

you do not use the 2nd argument in Instance.new() due to performance.

Oh that’s interesting. How come? I thought the extra line would cost perf slightly…

[KristinaMoment (Kristina)]

Oh true lol, thanks for thinking of that. Bit late now, although that would be an ideal solution

[ValtryekRBLX (Nexus)]

This is normally what I end up doing when I need to instance things in. However, I normally find just having everything there pre-run, and making it visible when needed works most of the time.

[DasKairo (Cairo)]

There is a post from 2016 explaining why, and how.

PSA: Don't use Instance.new() with parent argument

I’ve discovered a pretty bad performance issue in one of top games that has to do with Instance.new and wanted to write about this, since this is not obvious unless you know the system inside out. Tthere are several ways to create a ROBLOX object in Lua: local obj = Instance.new(‘type’); fill obj fields local obj = Instance.new(‘type’, parent); fill obj fields local obj = util.Create(‘type’, { field1 = value1, … }) If you care at all about performance, please only use the first option - I wi…

[KristinaMoment (Kristina)]

Ah, thanks to both of you

I would like your posts but I’m at the like limit…

[ifkpop]

What I usually do is create a the UI asset and set the script as parent.

local textLabelFloat = script.Template_GameFull -- Get access to it

... -- whatever you got between definition and first usage

local lbl = textLabelFloat:Clone() -- Just clone it, don't forget to set parent

This is an easier way to work with UI imo, since you can visually create it and edit it without having to write stuff in code for it.

Additionally, it is important you always parent after you change all the properties. I believe this is mostly important when doing stuff on the server, as the cost for replicating the changes is quite “high” compared to simply changing the properties first. However, it wouldn’t surprise me if it had impact on client only too.

Also: more lines of code does not always mean worse performance. While this is often true and a good rule of thumb, it’s good to know that it isn’t always the case.