When writing games, I am aware that images take up a lot of space. If one has a large graphical game, they don't want problems with memory, or to give players the message "Go buy a better computer to run this game". However, loading up images everytime one needs an image and discarding it is very slow. So if a programmer has a large graphical game, how can they draw many images without sacrificing performance/memory?
1.Use scaling; make images smaller, but still having enough to get the character around. Scaling an 80x80 in to a 60x60 saves a lot of space for five hundred images, seeing as each one will be 1/4th smaller, taking up virtually 1/4th of the space.
2.Use better compressed image formats; a BMP will save more time than JPEG, and is smaller.
3.Remove images that are no longer in a visible portion of the screen to save memory. In the 8 and 16-bit world this was mandatory, as having such tight memory and slow CPUs, on top of bank switching, made the process daunting to imagine for a C/Windows programmer these days. To recover the removed image, save where it was to an 8-bit byte container, and re-load it based on these coordinates. You can't lose with this method.
4.Don't load up too many images at once; I know this one is tough to comprehend, but tons of images at once isn't absolutely vital. In fact, it's not vital at all for a beginner program (which you seem to be, no offensive if you aren't) and cutting out a few extra images here and there make a stretch, but the saved memory and speed will thank you. Working with 3-D models, lots of large data files, and rendering is memory tougher. When you get there then it's time to work smarter, but as for 2-D games like a platformer, RPG, etc., my last three prior paragraphs should do the justice for you.
This probably isn't an issue you need to worry about. A typical image can be measured in KB, and few computers will choke if you're using less than 1 GB of memory, or even 2 GB. This leaves you space for hundreds or thousands of different images.
The first thing to ruin your performance will be rendering things to the screen, and until you already have something programmed and you're seeing it's too slow, that's not worth worrying about either.
I know this because it's one of my curses as well: One of the best ways to get nothing done is to worry about problems that haven't happened yet. Of course you should worry about some things (USE VERSION CONTROL / BACKUPS) but I think my intent is clear.