image/gif: FuzzDecode test runtime is excessive on various builders

[4a6f656c]

The image/gif.FuzzDecode tests take an excessive amount of time to run on various builders, even in short mode.

For example, on one of the linux/riscv64 builders:

$ ./gif.test -test.v -test.short
...
=== RUN   FuzzDecode
=== RUN   FuzzDecode/seed#0
=== RUN   FuzzDecode/seed#1
=== RUN   FuzzDecode/seed#2
=== RUN   FuzzDecode/seed#3
=== RUN   FuzzDecode/seed#4
--- PASS: FuzzDecode (286.02s)
    --- PASS: FuzzDecode/seed#0 (133.46s)
    --- PASS: FuzzDecode/seed#1 (2.94s)
    --- PASS: FuzzDecode/seed#2 (63.03s)
    --- PASS: FuzzDecode/seed#3 (66.32s)
    --- PASS: FuzzDecode/seed#4 (17.93s)

While I'm all for fuzzing, this is adding almost 5 minutes to each test run on this platform.

$ go tool pprof /tmp/p
File: gif.test
Type: cpu
Time: Sep 23, 2022 at 3:47pm (UTC)
Duration: 298.35s, Total samples = 284.61s (95.39%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top 10
Showing nodes accounting for 277.86s, 97.63% of 284.61s total
Dropped 234 nodes (cum <= 1.42s)
Showing top 10 nodes out of 23
      flat  flat%   sum%        cum   cum%
   100.01s 35.14% 35.14%    100.69s 35.38%  image/draw.sqDiff (inline)
    96.41s 33.87% 69.01%    272.35s 95.69%  image/draw.drawPaletted
    77.11s 27.09% 96.11%     77.11s 27.09%  runtime.memmove
     1.44s  0.51% 96.61%      2.35s  0.83%  compress/lzw.(*Writer).Write
     1.41s   0.5% 97.11%      4.25s  1.49%  compress/lzw.(*Reader).decode
     0.97s  0.34% 97.45%      2.25s  0.79%  image/draw.drawPaletted.func1
     0.35s  0.12% 97.57%      1.51s  0.53%  compress/lzw.(*Reader).readLSB
     0.14s 0.049% 97.62%      7.45s  2.62%  image/gif.(*decoder).readImageDescriptor
     0.01s 0.0035% 97.62%      2.77s  0.97%  image/gif.(*encoder).writeImageBlock
     0.01s 0.0035% 97.63%      2.95s  1.04%  image/gif.EncodeAll

This also shows on other platforms such as (total image/gif runtime, however FuzzDecode makes up the majority of the runtime):

freebsd/arm - 408.816s
linux/mips - 209.886s
linux/mips64 - 174.648s
openbsd/arm - 245.098s
openbsd/mips64 - 263.389s

I've not dug into the fuzzer, however at a quick glance it appears to be CPU bound on a single OS thread. I also know that a number of the above mentioned platforms are I/O limited (running on either SDMMC, USB or iSCSI) - not sure if this plays a part.

It seems that we should do at least one of the following:

1. Improve the performance of the fuzzing runs.
2. Reduce the amount of work that is being done in short mode.
3. Skip the fuzzing on a subset of platforms.

[4a6f656c]

/cc @rolandshoemaker

[bcmills]

While I'm all for fuzzing, this is adding almost 5 minutes to each test run on this platform.

Note that this isn't even fuzzing — it's regression-testing the existing inputs in src/image/testdata, which should be deterministic anyway.

Probably FuzzDecode should just call f.Skip if testing.Short() is true?

[rolandshoemaker]

Probably FuzzDecode should just call f.Skip if testing.Short() is true?

Yup seems reasonable, I vaguely remember having done this elsewhere before.

[gopherbot]

Change https://go.dev/cl/435175 mentions this issue: image/gif,image/jpeg,image/png: skip FuzzDecode in testing short mode