This is the key page for understanding how SQL Trace works and feeds into the I/O providers (rowset/SMO/Profiler is one of them).SQL Trace
The rowset provider, on the other hand, is not designed to make any data loss guarantees. If data is not being consumed quickly enough and its internal buffers fill, it waits up to 20 seconds before it begins jettisoning events in order to free buffers to get things moving. The SQL Server Profiler client tool will send a special error message if events are getting dropped, but you can also find out if you’re headed in that direction by monitoring SQL Server’s TRACEWRITE wait type, which is incremented as threads are waiting for buffers to free up.
Profiler impacts performance when implementing larges traces due to the number of events being fired. This would impede CPU/Memory[/IO] if there large number of events occuring.
Once an event fires, its data is routed into a global event sink, which queues the event data for distribution to each trace that is actively listening. The trace controller routes the data to each listening trace based on its internal list of traces and watched events
Hope this helps.