After some testing, I have found that the "duration" filter/column is a poor one to measure DML performance. The trace seems to pick up the duration for the entire elasped time for not on the DML to run, but its parse time, and connect/disconnect time for the transaction returning back to the end-user. For example, I have a app where (via ado) a connection is made, the query runs, returns the data to the com+ object which then wrappers it with xml and closes the recordset and thats it. Under profiler its telling me the duration is 20sec when in actual fact i only want to locate the SQL statement itself taking 20secs, not the total elasped time. As for this example, the query actually runs very quickly but is returing around 4000 rows. Its good to know of that the transaction's elasped time is XYZ but doesnt tell me the query is the bottleneck.
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"