Excessively slow and 100% CPU usage

[gtranter]

Using v2.2.1, running auto-changelog takes several minutes during which it consumes 100% (or as much as it can get) of my CPU (all threads), making my PC unusable until done.

Using v1.16.4 it completes in a few seconds.

In one test against the same repo in the same state, v1.16.4 took under 10 seconds whereas v2.2.1 took 5 minutes.

For almost all of the time, the status display is:

auto-changelog: 334 version tags found…

System:
Intel Core i7-9850H (9th gen. 6 cores 12 threads)
Windows 10 Professional
NodeJS 14.16.0.
Git 2.29.0.windows.1

Changleog template:

## Changelog

{{#each releases}}
  ### [{{title}}]({{href}}) ({{niceDate}})
  {{#commit-list commits heading='#### Fixes' message='fix|Fix' exclude='Merge pull request'}}
    - {{subject}} ([{{shorthash}}]({{href}}))
  {{/commit-list}}
  {{#commit-list commits heading='#### Features' exclude='Merge pull request|fix|Fix'}}
    - {{subject}} ([{{shorthash}}]({{href}}))
  {{/commit-list}}
{{/each}}

[cookpete]

v2 is much smarter about how it gathers the differences between two versions (see #144), and is useful for a bunch of use cases (namely #136 and #142). The downside of this is that it has to fetch the git log output for every version difference. When you have 334 versions this is likely to become slow, especially if some of the diffs have a large number of commits.

v1 just calls git log once and parses what it can out of that, but this has many downsides and can result in inaccuracies.

I would suggest using --starting-version to limit the amount of diffs it needs to pull in.

[gtranter]

Thanks for the explanation. although it's not what I was hoping to hear. I suppose we'll have to stay at v1.

I run the process over a semi-slow VPN connection, so I expect this could explain why it takes so long, but that doesn't really explain the pegged CPU usage I don't think.

The problem with using --starting-version is that it has to be updated/maintained so it does not fit easily into an automated build-deploy process. It would be far more useful if one could specify a "level" such as "all patches in this minor" or last 5 minor versions etc. - or even max 50 commits - not sure exactly how that would look but hopefully you get where I'm going.

[cookpete]

The problem with using --starting-version is that it has to be updated/maintained so it does not fit easily into an automated build-deploy process

I'm not sure I follow – you can just choose a --starting-version that reduces the processing time to acceptable levels and leave it at that?

You could also use the <!-- auto-changelog-above --> placeholder to avoid needing to generate the entire changelog each time.

[gtranter]

The starting-version would have to move once in a while or else eventually it will become slow again. This isn't just a matter of a repo that's been around for a long time - our repos are frequently tagged.

So being able to generate a changelog for "all changes in this minor version" for example would be super useful.

I'm still curious as to why the process is using 100% CPU when it's mostly waiting for git command responses.