I really wish people would not make sweeping generalization like 'Managed is too slow'. Like most sweeping generalizations, it is almost certainly wrong.
First, the original complaint was memory size, not speed. Second, that 300MB is NOT because the code is managed.
Ideally, people respond by attaching a heap profiler (like ClrProfiler), and discover the problem.
The problem is most likely a known issue. You will find in the KernelTraceEventParser the following variables
internal HistoryDictionary<string> fileIDToName;
internal HistoryDictionary<int> threadIDtoProcessID;
These allow better printing of kernel events, however currently they never discard entries.
This is fine for an ETL file (which is finite), however for real time it causes a 'leak'. This is on the TODO list to fix.
In the mean, you may not need these maps, in which case you can simply turn them off. However if you need their functionality you should contact me for further details.