Garbage Collector vs Pixi.js

[hashi]

Hello

 

Have an Important question. Is Pixi garbage-collector safe?

 

I've found, for example, kind of terrible pieces of code. I will not show them here, because they are easy to find. Just search for "splice" method in pixi.dev.js. You will find it used for deleting elements from array. But Splice always return an array with deleted element/s. In pixi it isn't grabbed to some var, so Garbage Collector will eat it and after eating enough of unused vars, GC will make a lag in runtime, because of freeing memory.

 

Wonder if there are more of memory-unsafe fragments, is Pixi GC safe?

 

EDIT:

Some other example:

PIXI.Rope.prototype.updateTransform = function(){    var points = this.points;    if(points.length < 1)return;    var lastPoint = points[0];    var nextPoint;    var perp = {x:0, y:0}; //:O object created every call of function

Instead of perp object it may be two variables, perp_x and perp_y, as you can see in the next lines (that aren't shown) perp is used only for some in-function calculations.

 

EDIT2:

 

Garbage Collector based on snake example:

 

Even better..:

 

[SolarJS]

Splice is bad, very bad, if you aim at low GC. However, if you look at the graphs you see that only each 60 seconds and in the second each 10 seconds GC will start. Also the amount it quite low, so it shouldn't cause too big lags.

[msha]

"But Splice always return an array with deleted element/s. In pixi it isn't grabbed to some var, so Garbage Collector will eat it "

 

"Instead of perp object it may be two variables, perp_x and perp_y"

 

Aren't browsers smart enough to optimize such simple cases?

If the returned value is not assigned to anything, why not dispose of it immediately...

[SolarJS]

Unfortunately they are not. Optimizers like Google Closure Compiler are able to find optimize those things (variable use), but they hit performance a lot if you have already programmed optimized code. So at the end it's up to the programmer. 

 

Regarding splice: For example this 1-item custom splice function has low GC / is nearly always faster than the browsers one, especially on mobile. https://twitter.com/SolarJSGames/status/524553896908566528

If you even track length by yourself is can be speed up even more.

[msha]

Unfortunately they are not. Optimizers like Google Closure Compiler are able to find optimize those things (variable use), but they hit performance a lot if you have already programmed optimized code. So at the end it's up to the programmer. 

Yeah I made a simple test and apparently Chrome  does not optimize those cases(GC acted somewhat differently on each refresh, but I saw the correlation).

 

Regarding splice: For example this 1-item custom splice function has low GC / is nearly always faster than the browsers one, especially on mobile. https://twitter.com/SolarJSGames/status/524553896908566528

If you even track length by yourself is can be speed up even more.

 

Nice. Maybe you should talk to Pixi devs on Github...

 

----------------------

This does not look like a huge problem though. In the bunnies demo, frames actually don't slow down when the GC collects(it might be different in other browsers and on mobile).

And I looked at several other game engines, and most of their demo games generate more garbage... 

[SolarJS]

If you target mobile, you should always start with mobile and test there first. Good testing devices (which means critical and tricky normal devices ) are Samsung S3 & S3 Mini (both in stock browser), iPhone 4, iPad 2 (with iOS 7.x or later) & iPad 3.