Declaring arrays/(or other objects) on behaviors, is there a "right" way? Anwser = No

Post reply
0 favourites
  • 7 posts
From the Asset Store
Array Editor
$5 USD
Supports 1D, 2D, 3D arrays. Import and export arrays in JSON format
paradine's avatar
paradine

  • Edit: According to Ashley, c3 does not pool objects behind the scenes. Advances in garbage collection have made this practice not nearly as important as it was 10 years ago. c2 used a generic pool behind the scenes, and recycled objects, but in most cases this isn't a concern anymore. In specific cases, where 100s of objects are being created/destroyed, pooling them is worth it, though either addonsdk/js will have far superior results than doing so in the event sheet.

    -----

    Hey all, I'm wondering, when creating a behavior,

    if I declare the following in the constructor for a behavior instance (instance.js): 

    this._state = [false, false, false, false, false, false, false, false];
			this._lastState = [false, false, false, false, false, false, false, false];
			this._enterTime = [0,0,0,0,0,0,0,0];
			this._exitTime = [0,0,0,0,0,0,0,0];

    Does that get recreated everytime the object instance gets created/destroyed? I know construct pools objects and so it isn't truly destroyed, but I wanted to make sure I wasn't creating a bunch of arrays that get garbage collected. If so, is there a better way to create arrays to avoid garabge collection in the c3 context?

    This will be on bullets, so thousands will be getting recycled every few seconds. Every tick I will need to save _state to lastState, and any changes or updates to states get logged in the corresponding _enterTime and _exitTime arrays.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • If you're asking if there will be a memory leak, then why can't you test it yourself?

  • I was asking about the lifespan of a construct object and how it is recycled behind scenes, if at all. Not so much worried about a leak, rather excessive garbage collection.

    Ashley addressed this in another forum recently, and as it turns out c3 does not use object pooling, Construct 2 used object pooling (to reduce the amount that the garbage collector would have to sort), but that is not the case with construct 3.

    As I understand it, Ashley chose not to bother with it because the advantages of pooling only really apply when 100s of objects are being created/destroyed every second; For those specific cases, its best to create low overhead objects and create a custom pooling solution yourself, as a generic one may not be as useful anyway.

    The advances in garbage collection in JS is vastly superior compared to 10 years ago when c2 used pooling.

    Garbage created on a frame to frame basis is handled with ease, typically in downtime between frames, and as such, it isn't critical to worry about creating JS objects to discard them each frame like it once was Major garbage collection is another beast and can cause some issues if a programmer is absolutely careless, but outside of creating large arrays and tossing them every few frames, there isn't too much to worry about. Even major GC is still effeciently handled these days in JS... My knowledge at the time of asking the question was about 10 years behind the times

    All that said, while object pooling isn't 100% necessary anymore, as it once was, I have found that creating and destroying a large amount of objects every tick still has a large enough impact to recommend recycling/pooling.

    Trying to manage object recycling via eventsheets, however, usually doesn't provide a large benefit as a consequence of increased event overhead. Therefore, I recommend either creating a behavior/plugin to handle it, or js module if you already have a lot of JS going on.

  • I vaguely remembered this warning but I'm not 100% certain it applies for you, posting it just in case.

    construct.net/en/make-games/manuals/addon-sdk/runtime-reference/object-classes/instance

    GetSavedDataMap()

    GetUnsavedDataMap()

  • Wait, now I'm super confused because this may indeed apply to me. This would be in instance.js

    I add properties like so: 

    constructor(behInst, properties)
{
	super(behInst);
			
	//This is what the example on github shows:
	//this._testProperty = 0;
			
	this._vx = 0;
	this._vy = 0;
	//etc...
}

    I also do this as well, outside of the constructor obviously, but still inside the main instance class : 

    get _someproperty() {
	return this._somecoolmath(42) + this.somethingelse + this.etc;
}
_somecoolmath(n) {
	return (n === 42? n : 0);
}

    Later, I us a weakmap in the scripting interface to provide a way to hook in editor side like so: 

    set vx(n) { map.get(this)._SetVx(n); }
get vx() { return map.get(this)._GetVx(); }
set vy(n) { map.get(this)._SetVy(n); }
get vy() { return map.get(this)._GetVy(); }
setVelocity(x,y) { map.get(this)._SetVelocity(x,y); }

    Is this not right? The example behavior on github doesn't really show anything else. I'm not sure what all constitutes a runtime class, but... ?

  • Aren't memory leaks and garbage accumulation the same thing?

  • Not at all! A memory leak in a managed language occurs when you have objects that can't be garbage collected.

    I said I wanted to avoid excessive garbage collection. "Accumulation", is a bit misleading, because you have memory that is either garbage, or it isn't, and it is basically defined as garbage by the collector. If the garbage collector marks something as garbage, it will be collected and so can't accumulate. You can create garbage, which will be collected, but a memory leak happens when the programmer has somehow mismanaged memory so that it can't be collected.

    Garbage collection (major/minor/whatever) takes time to operate, which is why I like to avoid it if I can. The more garbage you create, the more time it will take to collect. Long lived objects typically have a larger impact when removed, and there is an overhead per object that the garbage collector has to scan.

    A memory leak is a logical problem, in which the programmer has created references to objects that are no longer needed, but the references still exist on an object that is needed. A simple example would be if a character stored a reference to every bullet they shot in a list... Perhaps they have an ability that when triggered causes every bullet in the air to explode... Then when the bullet hits something, and is "destroyed" the programmer forgot to delete the reference in the list. Basically, you now have objects no longer in use, but they can't be garbage collected because the program still has a reference.

    In something like c++, a memory leak is way easier to accidentally create, because there is no garbage collector. C# is like js in that is has was to create leaks using action/delegates/lists/etc, where any function pointer can keep an object alive to which the function points, which in turn is keeping other objects alive, and so on.

    Memory leaks is simply memory that can't be released, despite no longer being in use. In managed languages, it just means that memory can't be garbage collected, though the collector will still scan it for opportunities to collect it.

Post reply
  • 7 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)