So here is a comparison point. For 'log tools' on bzr.dev it was 5m30s. 'log tools' using an updated 'filter()' method was 36s. 'log tools' layered on top of 'iter_changes [slightly incorrectly]' was also 36s.
However 'log bzrlib' with filter() was still 5m31s (the bulk of our files are under bzrlib), versus still 36s when layered incorrectly on top of iter_changes.
So certainly I think iter_changes() is the way to go ultimately, but that will be the next phase. I also want to look at whether I can cache the code that expands "tools" => tools/and/everything/else, because that doesn't change much between revisions.
So here is a comparison point. For 'log tools' on bzr.dev it was 5m30s. 'log tools' using an updated 'filter()' method was 36s. 'log tools' layered on top of 'iter_changes [slightly incorrectly]' was also 36s.
However 'log bzrlib' with filter() was still 5m31s (the bulk of our files are under bzrlib), versus still 36s when layered incorrectly on top of iter_changes.
So certainly I think iter_changes() is the way to go ultimately, but that will be the next phase. I also want to look at whether I can cache the code that expands "tools" => tools/and/ everything/ else, because that doesn't change much between revisions.