First of all to properly test two similar solutions, you’ll need to execute them separately in isolated files. Once you split up the files (and simplify the non-transaction solution a bit), we get the following times for an empty (columns only) file:
In this limited test, the transaction method is indeed faster by a few miliseconds. However you are forgetting two very important facts:
Nobody is going to run this in an idealized file with just columns
Revit’s internal database is total and utter crap ( sorry Autodesk but we have to be honest here)
These are very important because in an actual project, you’ll have walls and floors interacting with those columns and numerous beams connecting straight into them (also if it’s a structural model, you’ll get double the trouble because of all the analytical elements hiding in the background).
Plainly speaking, whenever you make a change to an element in Revit, the element’s entire entry inside the internal database gets rewritten and tagged for re-evaluation. Then all other elements interacting with the changed element also get tagged for re-evaluation, because that single change in the original element could possibly affect them. By not committing the transaction, you spare yourself the re-evaluation phase at the end but all of those changes that you did to the database now have to be undone again to bring the project file to its original state.
So let’s run this on a ~150MB file with about ~1000 column instances:
Python (real project):
The execution times appear virtually the same but the transaction rollback made Revit unresponsive for over a minute. The above is based purely on my own experience and observations, so take all of this with a grain of salt. No two projects are the same and there’s no guarantee that the above will always be the case. Just try it out for yourself on a few actual projects and see for yourself.