tslater2006
commented
6 years ago I would be willing to accept any performance improvements. I took a look at the branch and aside from the hard-coded directory path in PeopleCodeProcessor.cs (line 75) it looks good to me. Before a merge though similar changes would need to be replicated in the other delivered processors, specifically the populating of RepoPath.
ripleymj
I've got a POC of a few changes that speed up a Pivet run significantly. These are nowhere near ready to merge, but I wanted to start some conversation about what you'd be willing to accept.
Full timing output is here (with a few logging enhancements): https://gist.github.com/ripleymj/15e888ee9ec2d4241eb12a8b04ea9a26 and POC code is on this branch: https://github.com/ripleymj/Pivet/tree/perf-hacks
Running a Pcode extract of HR image 24 took 8424 seconds, with a subsequent run taking 1617 seconds. Moving the file path string replacement outside the nested loop/linq and storing that value inside a ChangedItem reduced the initial run to 3915 seconds, and a subsequent to 354 seconds.
I think I'd prefer to see this as constructor on a ChangedItem that accepts a full path, reads the global config, and transforms the repo path by itself, rather than burying that logic in all plugins.
Finally, libgit accepts an array of files to stage, rather than individual files. My suspicion is that it's accepting a file at a time, and resizing an internal array each time. Watching the progress bar here, it slows down as it progresses. Changing the staging code to just pass the full array to libgit reduces initial time to 1043 seconds, and a subsequent run to 340 seconds.
All of these were done with ChangeByOPRID enabled, so they may run even faster without that step.