That's the problem with a lot of folks' audit trigger code. No one tests with really wide rows. The tables I had to work with have between 100 and 137 columns with many too-wide character based columns that shred the normally accepted max row width of 8,060 bytes. Any generic triggers that have to copy the INSERTED and DELETED tables to be able to compare them dynamically or whatever will not do so well with such ridiculously wide-row tables. We had the additional requirement of having to carry forward certain data because the stupid ORM pre-filtered some of the data as "duplicate data" when it actually wasn't.

To be fair, I've not tested Pop's generic trigger code (although I've made similar in the past) in such a situation so I can't say that it'll run slow in such situations. I can only speculate based on past experience when such code makes copies of the INSERTED and DELETED tables for comparisons. It would be my absolute pleasure to be proven wrong and I will, someday, get around to doing such a test because generic triggers would be the bee's knees if they could be made to perform well.