I realiased that my post was a little terse, so I should try to qualify it a bit.

Say that you have a trace which captures SP:StmtCompleted. Say that you inside a stored procedure call a longer stored procedure that is not in the cache. Most likely you will find that StartTime for StmtCompleted for the EXEC statement and the first statement in the procedure will be quite a few milliseconds apart. This time span represents the overhead to call the procedure. This includes time for passing parameters, setting up table variables and most of all to compile the procedure.

The same applies for a trigger, but for a trigger there is also the overhead for setting up the inserted/deleted tables. This overhead can be seen in a trace as well, as the difference between StartTime for the statement that fires the trigger and the StartTime for the first statement in the trigger. However, if the statement that fires the trigger takes time to execute in itself, the waters get quite muddled.

Now, there is one more thing to notice about your trace: you include the events Showplan XML, Showplan XML Statistics Profile and Showplan XML For Query Compile, and if you include these events things like durations are distorted considerably, because they incur a very significant overhead. If you remove these events, you will see completely different numbers for duration.

You should use trace for these events in production evironments, except for very short periods. Tracing for these events can badly degrade the overall performance for your system. Note that even if you filter for a specifc spid, all processes start generating information for this event, and this is very costly. Believe me. I've sanka customer system that way. Very embarrassing.