cache (new feature): update multiple pages for a resource path concurrently

[salewski]

This issue pertains to ads-github-cache as included in ads-github-tools-0.3.3.

Updating paged chunks of data associated with a given GitHub v3 API resource path (e.g., /user/repos) can take a significant amount of time when the number of pages is large. This is true even though the current mechanism is checking the "ETag" of the cached object with the GitHub API to avoid pulling down pages of data that have not changed. Most of the time involved is just waiting for the round trip time of individual calls to the GitHub API, which are currently all performed sequentially.

It is expected that the total time could be significantly reduced if the ads-github-cache program were structured in such a way that it could make N requests at a time against the GitHub API, where N would be dynamically deteremined based on some TBD criteria (such as the number of available CPU cores, etc.)

[salewski]

This issue has been fixed for ads-github-tools-0.3.4 (released 2022-10-16).

The blurb about it from our 'NEWS' file:

*** issue #80: cache (new feature): update multiple pages for a resource path concurrently

    https://github.com/salewski/ads-github-tools/issues/80

    The 'ads-github-cache' program now updates (only if needed) the locally
    cached data for each page of a "paged collection". This new behavior
    creates the opportunity for all of the requests to make progress
    concurrently, since much time involved in such operations is waiting for
    the remote GitHub v3 API to respond.

    Anecdotal testing shows a significant real-world improvement. For
    example, the author's invocations of:

    :   $ ads-github-cache --verbose --update

    drop from more than two minutes (with the previous behavior) down to
    between nine and eleven seconds.

    See also the entry for issue #81, which describes how the concurrency
    works by default, and how the user may control its behavior.