As far as graphics are concerned, layers of alpha transparency can cause real slowdown, especially on Android devices.
Really though, the answer to 'What slows a program down?' is EVERYTHING! - every command has to be processed and they all take time, so the best way to have a fast program is to have an efficient program. That doesn't mean efficient or convenient for you. In the old days, experienced assembly programmers would sometimes make code as efficient as it could possibly be (within memory restrictions usually). Like if you have 10 distance checks, you would typically make a function and pass the 2 sets of coordinates for example, and SQRT the result and pass it back, that way you only need 1 function, and can call it from anywhere. But that's not what is efficient for your project... the most efficient and fastest way would be to calculate the SQRT for each case, no functions, no passing, parsing or checking of parameters. Of course, that's not really practical for most projects, unless it's there to show how fast things can be... the point is that it's good to be aware of calculations that eat up time, like SQRT, and consider ways of making them faster - do you even need SQRT for everything... Do you need to check distances every single frame... if you only need to check something 1 in 10 frames, then that means that bit of code is 10 times faster.
I mean, sticking with SQRT as an example, you might use that as a check between several enemy sprites, several bullets, the player... the number of checks becomes exponential, if you don't put a leash on it, it will slow your project down... so what else can you use to reduce the checks. These things are not hugely apparent without experience... people often assume that their game is so straightforward that there's no gains to be made in improving internal efficiency - those people did not have to program on 8-Bits and 16-Bits - hell some of the things we had to do just to avoid the slowdown when checking SIN() would make your hair curl
Comparing strings can be slow, it's always good to consider parsing your own arrays and using bytecodes when you can, so instead of having IF Enemy.Name="Pennywise", have IF Enemy.NameID=24, or use a constant (IF Enemy.NameID=#PennyWise). Comparing 2 byte values is quick, comparing text values is slow - especially if you rely on them a lot.
Look for the code that is used hundreds or thousands of times, that's where the meaningful gains can be made - keep recursive function code down to a minimum, try and avoid any IF conditions that you might not need... use the appropriate variable types... break down condition checks - remember that IF A=1 AND B=1 AND C=1 is 3 checks, all 3 are checked even if A=0... if you check A, B and C on separate lines then it can skip past them to the ENDIF instead of parsing them. The more layers of abstraction you're behind, the more impact these things have, and really Tier1 AppGameKit is abstracted a lot.
