Loading the output file and trying to do a diff was a bad idea, and added a lot
of unnecessary code. It was also broken after adding the markdown/html support,
as releases were being escaped a second time after loading originally. It was
my idea, not the AIs :(.
After removing this, the filtering logic was wonky (this was the AI), as
what was generated had multiple copies of identical functions, so the
sorting was ineffective, and there were multiple copies of the release
arraylist being copied everywhere. Now, releases are created once, by
the provider (before it was 1: via XML, 2: by the provider, 3: copied
again into all the releases, and then a compaction occurred prior to a
sort).
For all the sorting, and all the filtering, the release date was being
parsed (and allocated). That parsing now occurs once by the provider,
and is stored as an i64 that is used until the final atom generation.
Finally, GitHub results were being sorted by each page, which was then
thrown into the full GitHub results without regard for where they landed
again. This sort has been moved to occur after all threads have filled
the ArrayList
Benchmark 1 (3 runs): ./before config.json
measurement mean ± σ min … max outliers delta
wall_time 12.4s ± 800ms 11.7s … 13.3s 0 ( 0%) 0%
peak_rss 105MB ± 9.85MB 93.8MB … 112MB 0 ( 0%) 0%
cpu_cycles 6.56G ± 145M 6.40G … 6.69G 0 ( 0%) 0%
instructions 23.5G ± 613M 22.9G … 24.1G 0 ( 0%) 0%
cache_references 11.2M ± 273K 10.9M … 11.4M 0 ( 0%) 0%
cache_misses 3.30M ± 139K 3.16M … 3.44M 0 ( 0%) 0%
branch_misses 10.7M ± 724K 10.2M … 11.5M 0 ( 0%) 0%
Benchmark 2 (3 runs): ./after config.json
measurement mean ± σ min … max outliers delta
wall_time 11.8s ± 531ms 11.2s … 12.1s 0 ( 0%) - 4.8% ± 12.4%
peak_rss 94.8MB ± 3.81MB 92.3MB … 99.2MB 0 ( 0%) - 9.7% ± 16.1%
cpu_cycles 6.55G ± 54.1M 6.49G … 6.59G 0 ( 0%) - 0.1% ± 3.8%
instructions 23.2G ± 225M 22.9G … 23.3G 0 ( 0%) - 1.5% ± 4.4%
cache_references 10.8M ± 232K 10.6M … 11.1M 0 ( 0%) - 3.3% ± 5.2%
cache_misses 2.96M ± 59.0K 2.89M … 3.01M 0 ( 0%) ⚡- 10.3% ± 7.3%
branch_misses 10.5M ± 23.1K 10.5M … 10.5M 0 ( 0%) - 1.7% ± 10.9%
