I'm unsure what we should do about the benchmarks. I don't have a machine with more than 4 primary cores, which I don't think makes a good benchmark. Do you think we still need them? It currently only shows speed difference vs OptiPNG, though I think compression is equally notable.

Since there are many PNG optimizers out there, and the main deciding factors between them are speed and compression, I think it is important to keep the benchmarks up to date, even if only comparing performance with OptiPNG is somewhat limited. I could generate some updated numbers on an Intel Core i7-12700 CPU (20 logical cores, 8 performance cores) if that's okay with you!

Yes, that'd be great! I might see if I can update the script to simplify the way it works with the read me...

Did you have any comments on the change log or read me?

Right, I've updated the compare script with a couple of key changes:

1. It operates on the actual README file, so we don't need the separate template.
2. It no longer requires strip-ansi, so we don't need the node package files.

Did you have any comments on the change log or read me?

Other than what @ace-dent suggested, I think the documents are fine 👍

I'll try to do some benchmarks soon, although it's likely I'll be busy these next days.

I have just ran the benchmarks on a computer with a Debian sid Linux 6.5.0-2-amd64 kernel, an Intel Core i7-12700 CPU (12C 20T; stock clocks and cooler, but with turbo duration and power limits unlimited by motherboard firmware), and DDR5-5200 RAM in dual channel configuration. I used OptiPNG 0.7.7 as packaged by Debian. I compiled OxiPNG by running cargo build --release on this repository at commit c16519b38b0519988db625913be919d4f0e42f5d, using rustc 1.74.0-nightly (7b4d9e155 2023-09-28). No desktop environment or non-essential background processes were running during the benchmark.

The results were as follows:

Benchmark 1: ./target/release/oxipng -P ./tests/files/rgb_16_should_be_grayscale_8.png
  Time (mean ± σ):      59.6 ms ±   7.7 ms    [User: 77.4 ms, System: 3.6 ms]
  Range (min … max):    53.3 ms …  89.9 ms    32 runs
 
Benchmark 2: optipng -simulate ./tests/files/rgb_16_should_be_grayscale_8.png
  Time (mean ± σ):     132.4 ms ±   0.8 ms    [User: 132.5 ms, System: 0.6 ms]
  Range (min … max):   131.8 ms … 134.4 ms    22 runs
 
Summary
  ./target/release/oxipng -P ./tests/files/rgb_16_should_be_grayscale_8.png ran
    2.22 ± 0.29 times faster than optipng -simulate ./tests/files/rgb_16_should_be_grayscale_8.png

Benchmark 1: ./target/release/oxipng -o4 -P ./tests/files/rgb_16_should_be_grayscale_8.png
  Time (mean ± σ):      88.7 ms ±   4.3 ms    [User: 270.3 ms, System: 11.0 ms]
  Range (min … max):    86.8 ms … 109.4 ms    26 runs
 
Benchmark 2: optipng -o 4 -simulate ./tests/files/rgb_16_should_be_grayscale_8.png
  Time (mean ± σ):     444.9 ms ±   0.3 ms    [User: 444.8 ms, System: 0.7 ms]
  Range (min … max):   444.4 ms … 445.6 ms    10 runs
 
Summary
  ./target/release/oxipng -o4 -P ./tests/files/rgb_16_should_be_grayscale_8.png ran
    5.01 ± 0.25 times faster than optipng -o 4 -simulate ./tests/files/rgb_16_should_be_grayscale_8.png

In general, the relative performance of OxiPNG over OptiPNG seems to have remained similar over time.

Cool, thanks!
The outcome is expected - I've tried to keep the performance curve roughly the same in all the big changes I've made.
Do you want to commit the updated Read Me?

Yeah, I'll push a commit here with the updated readme!

@AlexTMjugador The compare.sh command should update the Read Me itself, did you not use that?

@AlexTMjugador The compare.sh command should update the Read Me itself, did you not use that?

I used it, but I didn't like how it formatted my CPU name as "12th Gen Intel(R) Core(TM) i7-12700" and did not make distinctions about the number of performance and efficiency cores, so I rewrote that a bit to look nicer in my opinion.

Ah, fair enough. Do we really need to keep the old benchmarks though?

Do we really need to keep the old benchmarks though?

I think they are useful for historical purposes. There is no harm in keeping them around for now.

My 2¢: Old benchmarks have zero value to users of the contemporary release. Even the latest benchmarks are just indicative of performance.
If dev's need the info for some kind of performance analysis(?), it can be seen in git or retested easily.

There is no harm in keeping them ...

Adds more noise for a new user to scan through when first encountering oxipng.

It's a bit more convenient to have the old benchmarks readily available than upon bisecting or checking the Git logs, and they are clearly labeled as old and not shown by default. But I don't have a strong opinion either way, and I don't mind removing them if appropriate.

Let's do this!