A single large tileset or Multiple tiny tileset?

This is a balancing act.

On the two extremes there are:

1) put every single tile into one gigantic image
2) put each tile into its own individual image

Option 1 works up until there are a certain number of tiles.
Option 2 also works on a lower number of tiles.

However, as you increase the number, each option leaves you a bit of a maintenance nightmare, as editing a huge image is hard to do, as is herding a zillion little individual images.

What to do?

Either organize them into multiple multi-tile images where the images should probably be related.

or

Still go with individual images, but organize them into folders.(I do this a lot in Silverlight)

The key here is "logical groupings"

And by logical grouping, I mean groups that are unlikely to be on screen at the same time, like your grass/snow/desert logical division.

For performance, it depends on how you are rendering

If you are using a 3D api, or a 2D api that uses 3d rendering, then you probably want to have some larger images, as texture switching is expensive.

If you are using a 2D rendering api that does not use 3D rendering, then you need to be careful of the capabilities of the rendering hardware (most modern graphics cards will do fine with whatever you want to do).

If you are using a library that composites UI images into a hierarchy of other visual elements, then you'll want to use individual images.

Here is my quick opinion:

You have two states: the edit state and the final state. In the edit state you make simple tilesets, making it easier for you to edit your maps inside of your editor if you quickly want to switch some tilesets. When you compile it for your final game, you can put them all together in a single big file - that is, if you don't intend to make them moddable in an easy way.

In fact, I use this approach for most of my game content. Right now I'm developing a bone class with dozens of additional calculations and exception handling, just for the editor part. But when it gets implemented in a game I'm gonna crop most of it, so only those parts remain that can run safely without throwing exceptions, and that runs with a good performance.

So:
editor state = maybe slow and loads of garbage, but easier to modify
final state = good performance/memory usage, hard to modify

Hope this helps.

The question is - how much data I would like to use at one moment.

Problem is - when you have a one colosal picture where is number of small pictures repeated all over - it's waste of memory.

so its up to technology you use:

Instantialization of pictures:
Use grid in whitch you just stores the number of the picture in set - so every picture is loaded just once an program is just making instances. It is huge optimalization. From browser technology - flash 10 can do it. Nonbrowser - allmost everything.

In silverlite or older Flash its waste of time - he stores each instance as a separate picture so there is best to use "one big picture" type - its much easier for maintenance.