More than expected number of AudioPeaksGenerator entries in log

This is no breaking bug, if bug at all, and is very low priority regardless. Maybe just a question of efficiency...and just wanted to be sure that nothing odd is going on.

In one case, I have 154 of the following entries appearing in the Rosegarden logs as a batch on opening Rosegarden sessionn. This is just the 58th:

[AudioPeaksGenerator] ctor Rosegarden::AudioPeaksGenerator(0x562c07c259c0) (now 58 extant)

True, they appear to be harmless...just noisy. On opening the session, it actually goes up to a lower number e.g. from 1 to 98 until I gradually scroll all the segments into view, at which point I get the remainder e.g. 99 thru 154 finding their way into the logs. Then those log entries go quiet for a while until I close RG at which point I get all of them again at one sitting. At first, I thought it was a different result starting from 153 going backwards until I noticed it went down to zero. In other words the usual programmer dilemma on where one starts counting. Since I don't particularly want RG using my JACK real time except for the essentials, I started a habit of scrolling all audio segments into view before doing any recording etc. But that is all just by the way.

What's odd, is that there are no where near that many audio segments in the composition? Being suspicious and as a test, I reduced the number of audio segments to something worth counting e.g. 29 over two tracks and intentionally had those same audio segments (i.e. linked segments) located further down the timeline. Now the AudioPeaksGenerator entries ran from 1 thru 58 which appears to make sense 2 x 29. But audio segments are links, not copies, so the peaks must be linked too?

The audio peaks cannot be different so why bother with all those extra log entries? Perhaps it's juat a loop through the segments regardless whether they are linked?
And when RG is closed, after not even visiting the audio segment tracks, let alone editing them...in fact, they happen to be archive tracks in this case, why all the apparent processing of peaks in the logs while closing?