png files (gopher subpackage) double-gzip'd

[extemporalgenome]

The png format already uses zlib internally for compression -- compressing it again is very unlikely to provide additional compression, and requires additional processing (once for your decompression, another time for the image library to decompress the png's pixels).

Large byte slices may also cause pathological behavior in the gc compiler (memory use ballooning). https://github.com/jteeuwen/go-bindata specializes in making sure the given binary file is compiled into a readonly memory segment without the major adverse effects -- though again, gzipping png files is best avoided.

[BurntSushi]

Ah, I did not know go-bindata had added an option to not compress data. (Haven't go get'd it in a while.)

I tried this out with the gopher image, and image/png.Decode is giving me an unexpected EOF error. When I go back to go-bindata with compression, things work. I'm going to do a bit more digging before I report this to go-bindata.

Large byte slices may also cause pathological behavior in the gc compiler (memory use ballooning). https://github.com/jteeuwen/go-bindata specializes in making sure the given binary file is compiled into a readonly memory segment without the major adverse effects -- though again, gzipping png files is best avoided.

Duly noted. This isn't a problem with the gopher package, since it's a toy only used in the examples. However, I'll keep an eye out for this in Wingo, where I'm using embedded binary data for fonts and images when nothing else is available.

Thanks! :-)

[BurntSushi]

I've removed embedded resources from Wingo since it ended up behaving exactly as you said it might: memory use ballooned during compilation. (Around ~2GB.)

As such, I'm closing this. Whether the gopher image is embedded properly is of no consequence to me here. It's small and only used in the examples.