Naming Lights
Giving a light entity a targetname makes VRAD compile a second lightmap "page" for the surfaces that its emitted light touches. This won't harm in-game performance, but it will increase compile time and BSP filesize, regardless of whether the light ever receives input to change its state.
However, the system can be overloaded if you try to make it handle a large number of overlapping named lights (since the number of pages needed increases exponentially). When this happens performance can be harmed and you may well see lighting anomalies.
VRAD attempts to avoid this with its hard-coded limits of two switchable lights affecting a brush face and 32 total pages per lightmap (a page exists for each possibility of combined states). More than this causes VRAD to throw a warning such as "Too many light styles on a face" and refuse to compute the lightmaps for those lights; this will make those areas appear as if they are not lit. You can help too by giving lights that will always change state at the same time a shared targetname, which makes VRAD merge their pages together.
Tip:If your game supports dynamic lighting system (
Black Mesa or 
Portal 2: Desolation for example) - use dynamic light sources instead of light and light_spot. This will reduce map size and make load times better. Don't do so in cases when dynamic light looks much worse then baked light, or when dynamic light causes big problems with performance.
Note:
- Light styles will affect page growth exponentially. To calculate the number of pages a brush face will have, take 2n where n is the number of named lights affecting the brush face.
- To reduce the number of pages created, light from named light entities is direct and won't bounce between surfaces. This can look very crude!
- Fix:
VRAD has a -bounceFromNamed parameter that can force named and styled lights to cast bounced lighting. Note that this will increase lightmap usage!
- Setting an animated appearance for the light counts as "naming it", even though the style key is incompatible with targetname.
- Pre-baked static prop lighting is always generated in with named and styled lights in their "off" position. If this is an issue, disable per-vertex lighting for the given prop.
- Cubemaps defined using env_cubemap will only store lighting for one state of the toggled light. If this is an issue, and the surface is not part of a static prop or displacement, manually define an $envmap and use a material proxy to toggle the $envmapframe.
Bug:There is a bug in the 
Left 4 Dead engine that affect the use of named lights. A named light, even if totally still will be considered fully dynamic by the engine and pump up a large chunk of frames per second until it is turned off and on for the first time. The workaround is to set the light to start turned off and to turn it on on map spawn using a logic_auto entity for instance. This could also affect 
Left 4 Dead 2, but this has not been proven. [todo tested in ?]
Warning:Although lights with the same targetname share lightmap pages, each light will still count as a separate edict! If using a bunch of lights with a shared name, consider removing the targetname from all but one of the light entities of a given name after compiling lighting, using a tool such as 
Entspy.
Code Fix:Modify VRAD to add a _targetname KV to lights that acts the same as targetname. This way, only one light will need a targetname, and the rest will have a _targetname that is ignored by the game instead.