Custom Library Crashed Studio

Hello, LetsGololly here! ^^
Today i have expierienced a weird bug.
To make this understand, i made my own library which just saves services + functions inside a table which is being returned, like every other module lol.
Heres an example of what i mean [important for the video]

But today something weird has happened to me. VIDEO TIME! :tada:


Cause you cant see my inputs, i was just trying to type : for WaitForChild (even tried with .) and studio started to crash. THIS HAPPENED 6 TIMES.
I tried to look into the crash log but its 12mb big and crashes my editor when i try to open it.

Every other script worked normally and then i went back to the bugged script. I typed in some lines after / before and then i tried it again
 and it worked?!
Very weird, but okay!

I thought it was better to post this in scripting support than bugs report [and i dont have access to it anyways]

I recommend not doing this anyways regardless of your reason, i’m assuming various scripts including client and server scripts will require this script. You end up using way more memory because you’re just making random references to services and whatnot that you won’t use. It’s the reason other programming languages don’t want you to make variable references that you don’t do anything with because it just uses up memory for no reason.

If you still do really want to do this have you tried adding prints? Try commenting out various services and test them, it’s probably something specifically like one line that is the problem. This really isn’t a fix or tip but you could also use the dot operator (.) instead of using [“”] indexing. It makes it look more clean. (although for future reference the dot operator can only be used with strings that have no spaces)

example

module.ServerStorage = game:GetService("ServerStorage")

This is also is a smaller point but you should just remove workspace entirely as a service in your module, the global version workspace is ~15900% faster than game:GetService("Workspace") and ~2700% faster than game.Workspace

2 Likes

interesting, thank you so much for this information! ^^
I think i could remove the service part, but i will probably still use the library for the function importing

It can definitely be of use, it’s just that it uses up more memory because you have useless variables that will never be used in some scripts, like imagine a singular script was made to get your data, and it uses the DataStore service and the Players Service, the other variables/data from the module would just be not used at all and would then be useless. This especially is true as your game grows because you’d have more scripts, and possibly might use a lot of different services for different things.

could i know where you got those stats? I just benchmarked all three by changing the name with the different way.
game.Workspace and workspace had around the time of 0.00007
GetService(“Workspace”) was bit slower with 0.00009
But where did you get the 15900% (159x), thats a HUGE difference

and from what i know some games do this too (i think psx used frameworks like this too from what i heard).
The module is like a reference so is it gonna really take up more ram? The framework module only gets called one time and then gets referenced EVERY time, ive tested it with a print and it got only required one time by the server and client even tho its being used than once

I used boatbomber’s benchmarking plugin, both on the new and old versions.

The green being the global, workspace, the blue being indexing for the workspace like, game.Workspace, and finally the red being the internal function game:GetService("Workspace").
The formula I used to compare each one into percentages was quite simple but it was
(x / y) * 100 - 100 , X being a number that’s larger than Y (these would be the data in the benchmarks provided by boatbomber’s benchmarker plugin.

The lower the better as that means it’ll take less time to run.
For these benchmarks I did 1000 loops (and I did 100,000 in the original data I gave you). As to actual benchmark something you can not just run it once. Also you can read the code here.

It is most definitely faster as workspace is a global that you already have access to at any point in a script whereas with game.Workspace you have to index the game for a child or property named “Workspace”. As for GetService("Workspace") it is also more slower as you are running a function, GetService() is a function, and so calling it and waiting for what it will return is slower, again this is just because workspace

It will take up more memory, yes. To store a variable in your computers memory you need to allocate more memory depending on how big it is. This is why in other programming languages that are lower level like rust, C#, C++, etc, they have specific types for different purposes.
For example i32 in a low level language like rust means that your computer it taking up 32 bits for that variable. While i8 means 8 bits and so on.

Low level just means no garbage collector, you manage the memory yourself, you have access to such things like that, even though Luau is high memory it does not mean that bigger variables don’t take up more memory, because it still happens. It is just how computers work in general.

The bigger the variable, or more things the variable stores, the more memory the computer is going to reserve for said variable in order to store all that data.

In summary, essentially the bigger the table, the more variables, unused, and what not, the more memory will be used. By having a module full of services that are required by various scripts, some of them will be unused per script that requires them, this now wastes more memory because you should and can just get rid of those variables as it is a variable/value/etc that will take up memory, and if it’s unused it should be deleted.

I mean if you really want to do this, I don’t think the performance is that big of a deal to hurt anyone, but people will 100% complain about it if they see it, as if it’s a better way to optimize your code in general, and doing practices that are save more memory are obviously better in general no matter how little, but it probably won’t be like saving 100 MB of memory.

Also one more thing, as your game grows this will probably matter since you’re gonna have multiple scripts requiring this module. If the module isn’t even being called more than once, why have it, it is more efficient to for one have all of the used variables in one script, as well as no need or hassle to index a module for a variable. As you could just have your variables be in the whole scope of the script, and you would just type out the name to reference them.

1 Like

ah, okay yeah that makes sense, but only the last part is something i dont really understand. Yeah every script require this library which only use some stuff leaving much unused stuff inside.

I made a forum asking if making those library will hurt the ram usage: Custom Library | Good Or Bad?

Now im again frustrating if i should use libraries or not :face_with_spiral_eyes:

Yeah that makes sense, as you get into scripting you’ll understand that more. For right now it doesn’t really matter too much it’s just something to keep in mind. You can use libraries but it doesn’t mean always that they’ll have for example shortcuts to services and things like that, they can be various things, like replicating the way a spring works or something like that to be used for UI Animations or other things like that. Overall I believe you should just make the variables you’re gonna use in your script, and if you won’t use them, just don’t make them, It doesn’t matter that much as most computers are fast enough to not care about unused variables and it wouldn’t really budge them in the slightest memory wise, it’s just something to keep in mind and if you ever work for actual companies it might be something to think about, but it the ease of a library that allows shortcuts to service in your opinion is more worth it than caring about micro-optimizing memory and what not, you can do it if you really want.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.