For those of you who don't know this, the game speed programmers discuss is practically the same as FPS , frames per second. We always try to make this as high as possibly, until a certain level; in Game Maker this level is also known as room speed. We can put the level infinitively high, although it will then never be reached, therefore we choose something reasonable that most computers will be able to handle, 30 is default. 30 frames per second will make graphics look good, and since most computers, in most games, can keep this level you can guarantee a good experience for all of your players. In some cases though, often when it involves a lot of drawing, your computer will not be able to reach this border, and what happens then?

Since game speed and FPS is the same, you will simply have fewer frames per second than usual. Because what you see works like an animation with many pictures put together you will now see when these images shift also. This means your character will not walk anymore; he will jump, freeze in position, jump, and freeze in position. Especially everything that is animated will look strange, since you only change sub-image when the frame is updated.

For game speed, which is equal to FPS, is also relative to the number of steps. Because room speed is the number of steps, and the room is only redrawn once in a step. And all code is also only executed once in a step , and here within lies the problem. But there is also where you will be able to make change and optimize!

If your room speed is 30, then the maximum amount of steps in a second is also 30. It will never do more steps than that, even though you do not even have any code in the game yet. But in every step it will execute all of your code no matter how long it takes; and this is the complication. If you have more code than what the computer can handle in 1/30 seconds this will produce the lag. The images will not update in time. Therefore our goal shall always be to have code that is not longer than what can be handled within the time.

To write such a code there is several things you must think of, especially if you're doing a large game. Here is a list of things I always regard;
If I want to display some value on the screen, like IP address, then I never draw the function itself. In a creation code I will save the IP address to a variable; and I will draw the variable, because a function is always slower than a variable.
If I have values that needs to be updated every step and is relevant to more than one instance, then I never do the calculation in all of those instances. If I have a value that is important to more than one object, then I never do that calculation more done once a step either. Every calculation is slower than to just read a variable; therefore I do the calculation in one single instance and I direct all other instances to there.
I am very careful with loops, especially if they have to be in multiple instances. For with one line of code you know it will not be devastatingly slow, but you don't know this with a loop. If you have a loop with three lines in it, and you have 20 instances of that object, it will be just as slow as 60 lines of code. If you make an RTS with 50 soldiers, and in every soldier you have a loop with ten lines of code, that'll be like a script with 500 lines. Try therefore to 1) use loops as little as possible and 2) try to limit the number of instances that run this loop
When using the particle system or similar, always be aware of what will happen. Even though you can't see it, the movement and the look of all the particles you create must be calculated and updated for every step, also. This code is fast; although as particles is often used in a huge amount it might get slow, in the end.
Imagine you have created a fire, using the particle system. Let's say it is a platform game, and the room is 2000 pixels wider. Tell me, why would that fire burn when you have already passed it by far? You can't even see it. This we must realize; that everything that sucks speed is bad, even though it doesn't have any practical effect. Effects like these (no matter if it is a RTS, platform, or RPG) should always be turned of when not in view. There are functions to deactivate objects, and those works perfect for this purpose.
One thing more that is very unnecessary is to have objects outside the room. For an example you might have a bullet, and it accelerates such that in step you've a put a code like speed +=1 speed += speed; that will be executed once every step. If you do not destroy the object when it goes outside room (when it has not hit anything), that calculation will be running again and again and again for no reason. Might not have any effect, but it's still not good. I never feel good about having objects I know I don't need.
Finally I shall say something about sprites and backgrounds also, even though they do not affect the game speed such as we know it. Sometimes you see a black screen before the room starts, that's where the graphics gets loaded. If you have this problem then you may try to preload big backgrounds etc. and you'll get rid of this. It looks better.

If you have any questions, feel free to comment and I will try to answer!