The helpful thing about VLANs is that you can place users into the broadcast domain that suits them. This is great if your network works like the old 80:20 rule, because that’s where most of their data will remain—inside their own VLAN. But that may not be the case, and you may need to transfer a lot of packets between VLANs.
In itself, transferring packets between VLANs is not a problem. Routers are very capable when moving data between subnets. The problem is that routers are traditionally a lot slower than switches, because they have to interrogate more of the packet, which naturally takes more time. Hence the development of MLS.
Given that there are different definitions of MLS, it is no surprise that MLS behaves differently on different platforms, employing different components. The 6500, for example, runs “classic” MLS, in that the first packet is routed, subsequent packets are frame-switched, and the whole process can be cleanly seen because the routing and switching functions are not terribly well integrated, even with the use of an internal route processor. This requires you to understand the flow process intimately and to be able to configure MLS on both routers and switches.
More modern switches, on the other hand, running an IOS that fully integrates the switching and routing processes, carry out the same process (route once, switch many), but do so internally, and therefore make a much better job of it. In fact, most of the process is automatic, transparent, and hard to examine.
Integrated switch-routers can forward data at incredible speeds due to the fast architecture employed. Is the routing (layer 3 switching) process much slower? Well, hardly, when you consider that the boxes all operate in a store-and-forward mode. Lots of time (comparatively speaking) is available during standard packet arrival latency for fast processes such as CEF to make up their minds how to forward packets or frames.