ObjectCache - a modern, blazing-fast model and part cache!

Sorry that you’re experiencing this! do you happen to have a reproduction file? I tried the following, and have had them send the objects back in their proper order:

local ObjectCache = require(game.ReplicatedStorage.ObjectCache)

local Obj = workspace:WaitForChild("Part")

local Cache = ObjectCache.new(Obj, 1000)

for Index = 1, 100 do
	local obj = Cache:GetPart(CFrame.new(Index - 50, 0, 0))
	obj.BillboardGui.TextLabel.Text = `{Index}`
	task.delay(5, function()
		if Index < 50 then
			Cache:ReturnPart(obj)
		end
	end)
end
1 Like

v1.1.0

Changes since v1.0.0

  • Improved initialisation times when creating a cache
  • Changed moving behavior to use one global table for better performance
  • Raised the global tables’ pre-allocated indices amount to 10,000
  • Added ObjectCache to wally! You can find it as pyseph/objectcache.

Fixes

  • Fixes an issue where if you called ObjectCache::ReturnPart on the same part twice, it would wrongly return another object.

cc. @527366

1 Like

Could you provide an example of moving a singular part in a bullet like fashion? The methods for this module are confusing and not really that clear on how to work it correctly. This looks like a very promising module, just need some more examples. Are you getting a new part and returning it to the far away cframe each time you want to update its cframe, how would this work with a trail? https://gyazo.com/f8808189cb10ffbf3d8770f3feb7c652

Creating a new instance with Instance.new() is costly.

Imagine if you have a gun and are shooting bullets. Instead of creating an entirely new instance every time with Instance.new(), you just create a pool of parts at the start, and keep reusing those parts for the bullets.

The demo file calls GetPart and ReturnPart every frame – which is meant to showcase how performant it is. In a real-world scenario, you would just call GetPart once when instantiating the bullet, and moving it with your own code – and then returning the bullet to the cache once it hits something or vanishes.

2 Likes

They were referring to blueberry posting the thread out of context, i.e. without proper reason.

1 Like

ty

blahbakhdjkashdkjhashdjkashkjdasdasd

ObjectCache v1.1.1

Changes since v1.1.0

None

Fixes

  • Fix ObjectCache::ReturnPart not properly marking a part as no longer used if PartCFrame was not provided
2 Likes

Forgive me if I’m stupid or not understanding something right, but you should add an option to create multiple parts to add to the cache instead of just one at a time if it goes over the predefined amount, similar to ExpansionSize in PartCache.

Also a InUse table would probably help it be pasted into existing modules that use Partcache

I might be stupid or it might exist but in the off chance that I’m not it would be a useful feature

You’re right, it only adds one object at a time when the cache is full - a more reasonable amount would be 10-50.

ObjectCache does keep track of in-use parts, and I can see how it can be useful. I’ll add both of these suggestions when I have time!

1 Like

Oh, what variable is used for this? Think it was _Objects but it looked like it was removed from both tables, so maybe there isn’t one. I can’t read through other developer’s code good haha.

You should make it a little bit like PartCache and rename some stuff so that people looking to upgrade don’t need to edit much and can drag and drop.

Just to clarify, the amount should be chosen by the developer, but I think you know it, just clarifying in-case.

ObjectCache v1.2.0

Changes since v1.1.x

  • Added Cache:IsInUse(Object) to determine whether an object is already in-use, i.e. is not free
  • Added Cache:ExpandCache(Amount) to manually increase the cache size.
  • Added Cache:SetExpandAmount(Amount: number) to determine how many objects are added into the cache each time the cache is empty. Defaults to 50.
1 Like

Cool update, pretty useful! If you haven’t already (i’m on phone) you should make it compatible with certain old partcache methods so people with old systems can drag and drop, but It’s not that necessary.

As well, there should be a way to get all parts that are in use, as well, or a table of all parts in use.

Also is this normal? Testing it with VoxBreaker.


image
It’s probably intended but it should probably just be one folder with the parts inside of it.

hi — yes, the folder behavior is intended. This is so that when the cache is destroyed, it just simply calls destroy on the folder rather than on each part individually.

1 Like

Cool :+1:
Would it not be possible to do that with the folder that is set to the cache holder?

Also, I just thought of this, there should be a method to remove an amount from the cache, would be useful for systems that decide cache size based on amount of players.

If you’ve ever looked at part chaches API, you know that literally anything is better than that.

:skull: kinda right, and this now has crazy useful features like the ability to expand the cache manually

I never really used partcache, just skimmed through it’s code, but it’s probably possible to expand the cache manually to an extent unless you change the code yourself

1 Like

Not to bother you, but can you confirm if this can/will be added or not, or if i’m an idiot and this is useless or already added @PysephDEV?

Cache:IsInUse(Object) achieves what you are asking for. I feel reluctant towards adding more methods and properties because I want to keep the module more minimal and clean in terms of source code. You can always edit the module’s code in your own game to add the features you want to use.

1 Like

Yes, but if you’d want a table of every part that’s in use without editing the module, you’d have to loop through every single one of them and call Cache:IsInUse(Object), sure I can edit the module, but it would still be useful to have by default. It’s still fine though, I feel like keeping it minimal is great for performance too and developers can edit it based on their own game’s code, I was only reccommending it for convenience :+1: