• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Discussion [SUGGESTION / QUESTION] Overhead in empty objects!

If I have an empty object, no events, not visible... anything at all... should it create overhead?!
Right now if I create a lot of these (empty) objects:

1) Memory rises (it's normal they exist) so it's OK!!
2) FPS drops... ?? NOT OK!!

I already talked about something similar before... If there is no logic associated with this objects, there should be no FPS drop..

QUESTION::

Now there will be people coming here and asking "how many empty objects are you creating"?! Well I'm creating 100000 or more (but that's not the point) and I'm not using them it's for test purposes only! (to discuss about how engine works.. and ways to improve it)

If I'm correct and people told me this before... "empty objects (with no events) generate no code entries"... so, and once there is no way to dynamically add code to instances (I think there was once before but there is no more) there should not be any excuse to have this kind of performance lost. But why is there?! (I'm curious! @Mike maybe you can answer me :) )

What I think the problem is: I guess the problem relies in the "auto existing code" for updating: position; vspeed, hspeed; speed; direction; angle... take note this is not related to the physics engine.. this is the hidden update code inside the objects (even if the physics is turned off).

SUGGESTION::

Would it be possible to make this instances have no CPU impact?!
The suggestion is, creating a function that makes objects,

1) not generate collision events with others!
2) not "auto" update
3) not draw
4) STILL ABLE TO EXECUTE EVENTS MANUALLY!!
6) they would still have the variables but they would not use them (kinda like deactivated objects but you could execute events in them!!)

I present to you.....

Code:
instance_make_inert();
(this does not exist! is a suggestion only)

DISCUSSION::

This objects should not to be in the "list" of per frame execution and if internally the objects stay out of the "execution stack", there should be no impact at all (apart from the memory impact).

I think this would be the biggest step towards "structs" (objects for just storing data that cause NO performance lost). I know some other engines... and creating 1000000000 of objects (to my knowledge) doesn't cause this kind of performance lost... because they are no being executed.

What do you think?!
 
Last edited:

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
Little known, but you can still access deactivated instances by ID, so you can do
Code:
/// instance_create_inert()
var r = instance_create(0, 0, obj_intentionally_blank); // or instance_create_layer\_depth.
instance_deactivate(r);
return r;
and work with that instance as per usual, without it taking up CPU resources.
Just don't forget to activate and remove it later.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
If there is no logic associated with this objects, there should be no FPS drop
Actually there IS a lot of logic associated with these instances (and they are instances if they are in a room, and objects if they are in the resource tree... ;) ). They have a great number of built in variables that are being updated or used each step of the game.

This objects should not to be in the "list" of per frame execution and if internally the objects stay out of the "execution stack", there should be no impact at all (apart from the memory impact).
Well, you have this, more or less. If you deactivate an instance in a room, you can STILL access that instance using it's unique ID value.

EDIT: Ninja'd. :(
 
Wooooow, I got @YellowAfterlife @Fel666 and @Nocturne attention!! It's an honor :p
My problem is that I wanted to still execute their events but manually!

So my suggestion was a way to not execute the "builtin variable update"!!

WORKAROUNDS::

1)

Code:
var a  = ds_map_create();
a[?"update"] = script_update;
a[?"draw"] = script_draw;
a[?"variable1"] = 12;
a[?"variable2"] = 11;
a[?"variable3"] = 10;
and treat maps as objects!!

2)

Code:
#macro b_update 0
#macro b_draw 1
#macro b_variable1 2
#macro b_variable2 3
#macro b_variable3 4

var b = ds_list_create();
b[| b_update] = script_update;
b[| b_draw] = script_draw;
b[| b_variable1] = 12;
b[| b_variable2] = 11;
b[| b_variable3] = 10;

You get the ideia! :p problem is that MAPS and LISTS... are slower --' I think so!!
And arrays.. are just messy! (good for STRUCTS, but messy for complex objects)!!
 
Last edited:

GMWolf

aka fel666
Wooooow, I got @YellowAfterlife @Fel666 and @Nocturne attention!! It's an honor :p
More so to be mentioned along with them! :)

When deactivating an instance, i believe you still have access to the instance. You can still see its variable, and execute script and events on them. Not sure about with though.
You just have to keep hold of the id and pass it to functions like event perform, etc.


You say arrays are messy? How so? I believe that i adress most, if not all the problems with arrays in my video. Plus, they have the advantage of being easily freed. As they are essentially garbage collected.
 
More so to be mentioned along with them! :)

When deactivating an instance, i believe you still have access to the instance. You can still see its variable, and execute script and events on them. Not sure about with though.
You just have to keep hold of the id and pass it to functions like event perform, etc.


You say arrays are messy? How so? I believe that i adress most, if not all the problems with arrays in my video. Plus, they have the advantage of being easily freed. As they are essentially garbage collected.
Well to my knowledge:

1) event_perform doesn't accept "ids"
2) event_perform_object is for objects not for instances so I cannot access instance variables while execution the event code (kinda like executing a method but with no arguments! ahahahah)
 

GMWolf

aka fel666
Well to my knowledge:

1) event_perform doesn't accept "ids"
2) event_perform_object is for objects not for instances so I cannot access instance variables while execution the event code (kinda like executing a method but with no arguments! ahahahah)
Oop,s thats true!
But you can still call scripts on it.
Simply pass the id as the first argument of the script, c style.
 
You say arrays are messy? How so? I believe that i adress most, if not all the problems with arrays in my video. Plus, they have the advantage of being easily freed. As they are essentially garbage collected.
Well thats true.. and I use them for a LOT of things...

the main difference here is that arrays/lists are sequencial and maps are not.
and forgetting a @ sign would not give a code error.. and still mess up all the game!

Now that I look at it again... maybe is just me being lazy!! :)
 

GMWolf

aka fel666
Well thats true.. and I use them for a LOT of things...

the main difference here is that arrays/lists are sequencial and maps are not.
and forgetting a @ sign would not give a code error.. and still mess up all the game!

Now that I look at it again... maybe is just me being lazy!! :)
Use enumerators, so they look like maps.
You could even use macros to have the @ccessor inserted, but that could get messy.
 
Use enumerators, so they look like maps.
You could even use macros to have the @ccessor inserted, but that could get messy.
hmmmm that would be a good ideia!!
macros with "@" inserted...

but if I remember correctly someone said in a previous topic that, when accessing data, using @ would make it slower...

Code:
var a  = array[@ 0];
is slower than:

Code:
var a  = array[0];
QUESTION::
I have one question (maybe @YellowAfterlife can answer this quicker, as he seems to be the test guy ;) not in a bad way).

when using ds_maps... storing data under key:

Code:
map[? 123] = true;

map[? 123]           // outputs true

map[? "123"]         // outputs undefined
knowing that "comparing numbers is faster than comparing strings" is it anyway faster to read a integer key then a string key?! or are they compiled to an HASH that is "as difficult to read as everything else"!! :p (now this made me laugh right now)
 
For the more curious (I'm amazed)

TEST::

Code:
#macro times 100000

s = 1;
repeat(200) {
    a = ds_map_create();
    s++;
    a[? s] = 1;
    t = get_timer();   
    repeat(times) {
        a[? s] += 1;
    }
    t = get_timer()-t
    show_debug_message(t/times);
    ds_map_destroy(a);
}

var s = "1";
repeat(200) {
    a = ds_map_create();
    s += "a";
    a[? s] = 1;
    t = get_timer();   
    repeat(times) {
        a[? s] += 1;
    }
    t = get_timer()-t
    show_debug_message(t/times);
    ds_map_destroy(a);
}
OUTPUT::

Code:
0.66  micro  // 1 [1 digit key]
0.87  micro  // 1 [200 digit key]

0.82  micro // "1" [1 char key]
1.17  micro // [50 char key]
1.93  micro // [100 char key]
3.13  micro // [200 char key]
 
Last edited:

GMWolf

aka fel666
For the more curious (I'm amazed)

Code:
#macro times 100000

a = ds_map_create();

a[? 1] = 1;
a[? "1"] = 1;

var t = get_timer();
repeat(times) {
    a[? 1] += 1;
}
t = get_timer()-t
show_debug_message(t/times);


t = get_timer();
repeat(times) {
    a[? "1"] += 1;
}
t = get_timer()-t
show_debug_message(t/times);
OUTPUT::

Number version: 0.41 microseconds per iteration
String version: 1.37 microseconds per iteration

though it does not increase with the complexity of the string!!
Code:
a[? "1"] += 1;
a[? great"] += 1;
a[? "super great"] += 1;
a[? "incredibly great"] += 1;
a[? "qwertyuiopasdfghjklzxcvbnm"] += 1;
have the same performance!!
That is interesting. I wonder what kind of hashing function is used...
Could be like nava where the first n characters are hashed.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
knowing that "comparing numbers is faster than comparing strings" is it anyway faster to read a integer key then a string key?! or are they compiled to an HASH that is "as difficult to read as everything else"!! :p (now this made me laugh right now)
If I remember correctly, ds_maps are implemented as hashmaps with lists of key-value pairs inside. This means that a list of potential pairs (sharing the same hashcode) is retrieved first, and then the program looks, if any of them has the key matching the requested one. This is why GameMaker allows to mix numeric and string keys in the same map, and also why access speed depends only on hashing time of the key.

On HTML5 it uses JavaScript objects as hashtables, which means that all values are converted to strings first, and map[?1] is same as map[?"1"] (alas, "mixed key" type maps are not viable on JS)

Also, don't use the [@] accessor for reading, only for writing.
 
Top