Should I Parent The New Sound Object in the Player Object or SoundService?

I’m scripting Super Stela Games 2, which is a new game on ROBLOX but this time, I’m scripting to make sure it’s organized so that it’s easier to keep track of the game’s code and to make sure the script runs efficient to prevent no memory leaks.

When I script to play sound locally, I usually parent it under player GUI or the player object under game.Players. I haven’t tried parenting the sound to soundservice but I’m considering doing it to organize the game more and it might make the game run more efficient because soundservice is designed to store sound there.

What are the pros and cons of parenting a newly created script under soundservice or under player object under game.Players or player GUI to play a sound locally?

1 Like

You can’t possibly create a memory leak on ROBLOX. You don’t have access to the heap. It’s all managed under the hood for you. You’re only dealing with the stack.

Also, the garbage collector will pickup any unused object with no references.

It doesn’t matter where you parent the sound. If you’re worried about sounds being parented all over the place, just add:

  yoursound:Play()
  game.Debris:AddItem(yoursound, yoursound.TimeLength + 1)

It will automatically have it disposed after 1 second and allow the garbage collector to clean up.

2 Likes

Excuse the irrelevance of this, but I have to reply just to say how much I enjoyed you called Debris the “garbage collector”. :laughing:

3 Likes

I wasn’t calling the Debris the garbage collector but now I see how the wording may have thrown you off :laughing:

I meant to say the Debris would dispose of the object. Then later on, the garbage collector will pick it up.

2 Likes

Memory leak could happen on ROBLOX. It’s unrelated to this topic but here’s one scenario that could happen. I can save that for a different topic but I’ll explain one example of it.

  1. The local script is parented under screen GUI and the viewport frame is parented under screen GUI
  2. A local script calls a remotefunction to retrieve a model stored in serverstorage. It looks like this

local modelRequest = game.ReplicatedStorage.getModel:InvokeServer()

  1. Then a script on the server creates a local table and returns it that looks like this:

    function game.ReplicatedStorage.getModel.OnServerInvoke(player)
    local vpModel = game.ServerStorage.Model:Clone()
    vpModel.Parent = game.ReplicatedStorage.Cache
    local table = {
    [“viewportModel”]=vpModel,
    }
    return table
    end

  2. Then back in the local script

    local vpM = modelRequest[“viewportModel”]:Clone()
    vpM.Parent = script.Parent.ViewportFrame

Let’s say that if a player kept on clicking a button to load a model in server storage to the player’s viewport frame, a memory leak could definitely happen.

This is one example but I can discuss with it more in a different topic.

1 Like

No it won’t, because you’re still parenting the object to the ReplicatedStorage. It resides under a parent (still being referenced), it’s just not being used directly. It’s like having a pointer to an object but not accessing that pointer. It’s redundant.

That code just instantiates an object and places it under ReplicatedStorage. Then, the client clones their own copy on their machine.

Even if you didn’t parent the object in ReplicatedStorage, the variable would go out of scope as soon as the return is triggered. Meaning the server has no reference to that object anymore. The garbage collector will free the memory it used up.

You cannot create a memory leak on ROBLOX. I think you’re mistaking the difference between not using an object and a memory leak.

A memory leak is when you create objects on the heap, then remove all pointers and references to that object without freeing it from memory. The program will have no way to access the memory it originally allocated unless you access that exact memory address and overwrite it.

If an object loses all its references, the garbage collector will dispose of it. ROBLOX takes care of the heap under the hood. You can only create variables on the stack. Which is automatically handled by the garbage collector.

If ROBLOX was prone to memory leaks, it wouldn’t have the reputation it has today. It’s very embarrassing for a company to release software that causes memory leaks. Especially how ROBLOX is meant to teach kids how to code. If they would allow kids to manually handle memory, it would be a nightmare. You’d be able to crash a whole PC just by allocating memory manually on the client in a while loop.

1 Like