Instantiate multiple objects for procedual map

The short answer to how to do this is Keep It Super Simple.

Instantiating a multitude of planes is not the correct approach in most cases because it does not scale very well at all. If going this route, you should consider:

• set up occlusion culling of some sort, even if it's just as simple as disabling the renderers for everything and only enabling the ones in view, disabling/enabling as they leave/enter view. Distance fog can help with hiding this as long as you aren't zooming/moving closer or farther.
• maintain some sort of level of detail objects such as simplified models, simplified scripts, etc that you swap in when things are far enough away.
• constantly stream the world in a bit at a time, only instantiating what is visible and necessary and gradually instantiating other things over time.

Instantiating only what is visible and destroying what is not tends to fall apart if you go back to previous areas and changes made there do not persist, but in some games, that's OK. To mitigate this problem, you could maintain some sort of simplified state representation(s) of the world that you write to as things change.

Regardless of the system you use, whether you are using the terrain system, a mesh from a 3D app or just one or more planes, the idea is to only use what you need and to simplify what you need:

• Don't forget to mark unmoving objects as static.
• Combine your meshes and to have them share as much as possible.
• If you can do without things like collisions or physics simulation, then remove them or at the very least turn off layer collisions between some layers.
• Use simpler colliders - Why use a complex mesh collider when a box collider will do?
• Consider increasing your FixedUpdate step.
• Use prefabs and share them.
• Use fewer materials, sharing and combining materials and textures wherever possible.
• Use simpler shaders.
• Use simpler lighting, baking whenever possible.
• If your textures are never seen at high res, use simpler textures.
• Use simpler models. Unity can push a lot of polygons, but there is a point at which enough is enough and it is just senseless to waste processing on detail that will never be seen.

If I get your purpose for using these tiles, then it is likely you intend to use them for selection and/or storing what is placed where or something like that. It is prudent to use fewer planes, and simplify interaction and storage:

• perform simpler selection and interaction scripting, which can be done by using a single raycast and checking the hit point against your known coordinates for the tiles/plane(s) to determine where/what tile was hit.
• store information about tiles in simpler script variables rather than parenting and multiple GameObjects, etc. that would all have to be rendered, etc.

You should always strive to simplify code as you go, using fewer and simpler computations, but script optimization is for many very good reasons usually done much later on. There are a great number of optimizations that can be performed in code, but the general theme is to be lazy (do less and spend less doing it). There are whole lectures on code optimization, but here are some things to consider:

• Use FindWithTag instead of Find. Find is very slow and expensive.
• Whenever possible, use distance squared rather than distance (each square root is very expensive).
• Don't perform Vector3 or more complex calculation when you only care about one float of the Vector3 or some simplified case.
• Rotations can be expensive, simplify or remove them whenever possible. Performing/storing your own by Quaternion is cheaper than calling Rotate or calculating euler angles (which are expensive to calculate and back).
• Addition is cheaper than multiplication.
• Simplify your loops. Fewer, simpler loops.
• Combine your logic statements, taking advantage of short-circuit evaluation by ordering logical expressions from cheapest to most expensive. switches are cheaper and faster than a multitude of if-else.
• Exit early whenever you can.
• Messaging and OnX event functions have some overhead to them that can be avoided in many cases with simpler computation on your part.
• In the worst case, you could always re-implement the classes and functions that Unity provides. It is a fact that they are actually quite a bit slower than they could be, but there are reasons for this and should usually consider this a last resort approach.