Weil je größer das transaction log wird, desto langsamer wird die Sache...
Das ist pauschal nicht richtig und vielleicht auch nicht im Fall von SQLite.
Erstmal
Transaktionen sind nicht dafür geschaffen, schnell oder langsam zu sein, sondern fachlich richtige Datenoperationen zu granatieren.
Braucht man das nicht oder wird es nicht so von der Datenbank unterstützt, kann man rumwurschteln wie man will.
Verwendet man Transaktionen im Sinne fachlicher Transaktionen, dann muss der Log Mechanismus entsprechend dimensioniert sein (Platz haben) und idealerweise auch darauf optimiert sein, möglichst flott zu arbeiten. Das ist dann Aufgabe des Admin, sowas nach Bedarf bereitzustellen.
Und mal als kleines Gedankenexperiment:
Was ist schneller?
1 Millionen Inserts plus
1 Millionen Commits
oder
1 Millionen Inserts plus
1 einziges Commit
Ein Commit als Programmschritt ist tatsächlich als eine Art Overhead zu sehen, die Sicherheit einer fachlich vollständigen und richtigen DML Operation (egal wie groß) bekommt man nicht geschenkt.
Wenn SQLite tatsächlich mit vielen kleinen Transaktionen (commits) schneller ist, dann würde ich das als Besonderheit von SQLite sehen.