63 replies to this topic

[Tarik]

How many of these 'tips' were actually tested? To be entirely honest, there's so many half-truths in this topic I'd rather see it closed.

For example:
24. Use display_set_colordepth(coldepth)

That's something I'd be very skeptical about. I remember doing multiple tests over the years and 16b color depth never gave me any performance or memory improvement.

Setting the game priority to a higher level is not something I'd recommend either, as it can obstruct non-game processes that actually support the smooth performance of your game.

Using DLLs is also not just something you can recommend in 1-2 lines of text, without going into at least the minimum overhead you incurr for making calls, even if the dll is entirely empty.

Spending so much time discussing variable memory, disregarding the fact you can store over a million numbers, each bigger than 9 quintillion, and use less than 10mb of memory of your typical 4.000mb ram.

Deriving performance estimates from syntax, as Yourself explained.

Various outdated and obselete functions for GMS.

---
I'd say, for anyone who doesn't know how to optimize their game, they probably don't know enough to sift through the nonsense in this topic and end up spending hours on eliminating 20 local variables that take 160 bytes, create a 16bit color depth option and end up writing code based on assumptions of syntax rather than empirical data of how certain syntax performs in GM specifically. Whereas the people who can sift through that nonsense, probably aren't helped by things like 'avoid memory leaks' or 'use surfaces to tradeoff reduced drawing calls for increased memory'.

In other words, does more harm than good. These topics are super interesting, but you can hardly take them seriously if they're void of even a little basic measurement data.

[Liorana]

The problem I had with your original statement was that you were making a guess about the performance of a high level language based on its syntax.

Problem with this statement is that it guess that I was guessing... i did those test long ago. I just did them again with different specification to show you the performence difference.

As for your test, I have a hard time believing that 5000 iterations was enough to produce a noticeable difference in execution time

that makes it 5millions per seconds when ran at 1000 fps anything will show a difference at that speed in game maker.
case statement came at almost exactly 1 million a second while if was slightly higher than half a million.

For example:
24. Use display_set_colordepth(coldepth)

That's something I'd be very skeptical about. I remember doing multiple tests over the years and 16b color depth never gave me any performance or memory improvement.

I know it does that in other games but i don't know about game maker.... one of my friend was lagging like hell in a game in some areas... we told him to lower his color to 16 bits and then he was fine after that. but yea... that's not game maker. so maybe it was just assumption. but i would assume that as well. maybe its a huge factor on onboard video card.

[Gamer3D]

It turns out that in C#, this switch statement will be no faster than the equivalent if-else statement. The reason is that the if-else statement and the switch statement end up getting turned into exactly the same MSIL bytecode (this is really only true for strings and really only true for a small number of cases, if the number of cases is large enough the compiler will actually build a hash table of the strings and use the MSIL switch instruction).

How switch gets parsed depends on the language and compiler as well. I will use the following example switch statement:

switch x {
  case 0: y = 0; break;
  case 1: y = 1; break;
  case 2: y = 2; break;
  case 3: y = 3; break;
  case 4: y = 4; break;
  case 5: y = 5; break;
  case 6: y = 6; break;
  case 7: y = 7; break;
}

If a switch statement is sufficiently large and the control variable can be sensibly converted to a small integer (for GM, this would be quite tricky, but potentially possible), it becomes more efficient to create a lookup table with pointers to compiled code. In pseudocode, it looks about like this:

jmp jump_table[x];

If this is implemented in GM, it will probably be done by discarding the lowest 12 bits (if it's a number) and hashing the remaining variable (the hash function might be quite simple, and can be chosen based on how well it divides the cases). This hashed variable can now be used for the jump table. Of course, after the jump, you will have to compare with a value (to handle the default case) or two (in the event of hash collision), but it still reduces N if-statements to single hash, jump, and if-statement.
One last note: The continued execution of statements (if no break statement is placed) can be emulated by copying code, duplicating jump pointers, or by arranging the generated code properly.


It can also be treated as a series or tree of if-statements:

if (x=0) y = 0; else
if (x=1) y = 1; else
if (x=2) y = 2; else
if (x=3) y = 3; else
if (x=4) y = 4; else
if (x=5) y = 5; else
if (x=6) y = 6; else
if (x=7) y = 7;

if (x<=3){
  if (x=0) y = 0; else
  if (x=1) y = 1; else
  if (x=2) y = 2; else
  if (x=3) y = 3; else
} else {
  if (x=4) y = 4; else
  if (x=5) y = 5; else
  if (x=6) y = 6; else
  if (x=7) y = 7; else
}

We can expect approximately n/2 comparisons when evaluating the if-series, and log2(n) + 1 comparisons when evaluating the if-tree (if no leaf of the tree becomes an if-series). Note that at some low enough level, it becomes more efficient to stop splitting the tree and implement it as a series instead.

[TheValeev]

16. Use DLL's

GML is a interpreted language. And interpreted languages are most of the time slower than a compiled language.
So use DLL's for performance critical code. They can be a lot faster.

 

So what "critical code" you mean? And what DLL's I can use for example?