--benchmark, fixes #217

[gurgeous]

This is not done yet, but I thought you might want to take a look. Maybe something like this? See sample output below. A few questions:

• should I add tests? not sure if that's useful here, let me know
• I could try to load/use TableTennis if available, without adding a dependency.. any interest?
• want me to modify the changelog? anything else?

Thanks!!

$ image_optim --benchmark -r /tmp/corpus/

benchmarking: 100.0% (elapsed: 3.9m)

BENCHMARK RESULTS

name      files  elapsed  kb saved     kb/s
--------  -----  -------  --------  -------
oxipng       50    8.906  1867.253  209.664
pngquant     50    1.980   214.597  108.386
pngcrush     50   22.529  1753.704   77.841
optipng      50  142.940  1641.101   11.481
advpng       50  137.753   962.549    6.987
pngout       50  426.706   444.679    1.042

[gurgeous]

One rubocop issue remaining:

lib/image_optim.rb:28:1: C: Metrics/ClassLength: Class has too many lines. [170/150]
class ImageOptim ...
^^^^^^^^^^^^^^^^

There are many ways to fix this, but I always try to avoid refactors in other people's projects :) Happy to address this if you give me some direction.

[toy]

Sorry for the wait. Works well, most important comments are for lib/image_optim.rb, everything else is code style and nitpicks.

About tests - better to know if it will break, so at least on the level of that it works.

About TableTennis - I understand the desire to make it beautiful, but the output is so simple, that it feels excessive. From one side it shouldn't add more than few lines of code, from the other there are lots of different gems to print a table in terminal and everyone may have their preferred one.

About changelog entry - definitely and some mention in readme

[toy]

I'm not sure if applying worker always to the original is more informative then doing it in chain (on result of previous worker) as will be done during normal operation

[gurgeous]

Maybe we can add a --chain later if people like this. I think those results would be interesting as well, especially now that I've seen the worker_analysis script

[toy]

worker_analysis is there to understand tool interaction, try different options, in the end decide about usefulness, order. When using --benchmark I think it may be confusing if two tools report reduction by 50%, but when combined - only by 51%

[gurgeous]

Thanks for the feedback! I added a simple test and applied the feedback. I think this is ready for another look now, no rush

[toy]

worker_analysis is there to understand tool interaction, try different options, in the end decide about usefulness, order. When using --benchmark I think it may be confusing if two tools report reduction by 50%, but when combined - only by 51%

[gurgeous]

OK, thanks for the feedback. How about this? No rush!

[toy]

@gurgeous For me the biggest question is still about showing worker efficiency in isolation instead of the way they would run in chain when applied on result of previous (see my comment). Can you describe why you want to go with the isolated way?

[gurgeous]

@gurgeous For me the biggest question is still about showing worker efficiency in isolation instead of the way they would run in chain when applied on result of previous (see my comment). Can you describe why you want to go with the isolated way?

Ah, yes. I use image_optim as part of my build. My personal goal is to identify and eliminate the image_optim tools that provide little benefit for my use case. I don't need to squeeze every last drop of optimization out of the system, and speed is very important.

With --benchmark this is crystal clear (see top results). I need to run with:

--no-optipng --no-pngout --no-advpng

In fact, I could probably get by with oxipng alone...

No worries if this feels out of scope for image_optim. I'm very happy with the tool and I appreciate all your hard work!

[toy]

It can call out very slow tools, but it doesn't show how will the tools behave in chain (also probably they take same amount of time, but with less effect). Also reminds of a very old issue #10, as tools with faster configuration can be very quick and still optimise images a bit. So to have a good picture it would be better to have a way similar to worker_analysis especially with multiple variants. But if it helps the way it is - good. What do you think about changing the option to require type, so that the call for current would be image_optim --benchmark=isolated (isolated is just the first name that I thought of, maybe you have a better idea)?

[gurgeous]

I would love to see a --chain that is similar to --benchmark but reports on chains. Maybe that should be a separate effort/PR though?

[toy]

I'm not suggesting to add chain benchmark here, just make current variant explicit like image_optim --benchmark=isolated so then another can be added to work like image_optim --benchmark=chain (or chains?)

[gurgeous]

Ah, I see. That sounds good, see latest commit.

[toy]

I meant the type to be required, also OptionParser gives an option to check valid options:

  op.on("--benchmark TYPE", [:isolated], "Run benchmark in one of modes", "isolated …") do |benchmark|
    p benchmark
  end

Also probably disable Metrics/ClassLength for ImageOptim class