After processing each RideItem, call freeMemory to deallocate the RideFile
object inside it, since we're done with the RideFile once we have the
BikeScore. Also call computeMetrics instead of htmlSummary, since we only
need the BikeScore and computeMetrics is faster.
After computing the stress cache from scratch on Sean's ride library
(3 years of rides), this change reduces the process virtual memory size
(VSIZE) from 769 MB to 412 MB. Even more dramatically, it reduces the
resident set size (RSIZE) from 389 MB to 36 MB!
On Sean's MacBook, which has 4 GB of RAM, this change results in a modest
reduction in the time to compute the stress cache, from 17 seconds down to
14. On machines with more limited memory footprints, or when dealing with
a larger ride library, the speedup could be very dramatic. (Once the
process starts paging, it's going to crawl.)
Now that it only takes 14 seconds to calculate, it's really not clear to
me that we need store the stress cache on the filesystem at all.
This old compatibility mode was only used to verify that we could match the
output of an old version of PowerAgent, and it hasn't been used in GC in a
long time. I can't see us ever using it again, either.
I don't think that our zones or CP changing should require re-opening the
notes file. Only changing which ride is selected should do so.
This commit is the follow-on to a85c4f. Please review.
I have no idea why we were saving the current notes file and opening a new one
every time we called generateWeeklySummary, but it seems totally wrong to me.
This commit merely separates the two concerns into two separate functions,
generateWeeklySummary and saveAndOpenNotes, and calls the latter everywhere
the former is already called. As such, there should be no functional change.
We can work out whether we should really be saving (possibly empty) notes
files in all these places as part of a future commit.
...so that the intervals summary is "above the fold". That may be a little on
the wide side for small screens, but it's still less wide than the intervals
summary, so it's not the worst offender in that regard.
The recording interval can vary. If the recording interval is not 1
second, then the data is linearly interpolated for the time period at
1 second intervals. This allows for smart recording or garmin 705 data
drops to work correctly with GC.
Powertap .raw file containing data for speed, cadence, hr, and power.
It also has a few intervals markers which may be useful for verifying
that we handle intervals correctly.
