EIO_MEMORY_LIMIT

It's no secret that EWWW IO's bulk image scanner can be a little memory hungry. On a small site, it's not so bad, but on a large site, it can eat up a lot of memory. However, the bulk scanner at least tries to live within the memory limit that you've defined in PHP. Most of the time, this works just great. Sometimes, web hosts have things locked down so tight that it can't detect the memory limit. Then, EWWW has to make an assumption: it assumes that there is at least 16MB of free memory, and attempts to work within that space.

If you would prefer that it made no such assumptions, and would rather tell it exactly how much memory should be available, you can define EIO_MEMORY_LIMIT in your wp-config.php:

define( 'EIO_MEMORY_LIMIT', 256M );

Please note that this is not necessarily all used by EWWW IO, you need to account for what your other plugins and your theme are already doing. You should generally set this to the same value as PHP's memory_limit setting, to make sure there is still some wiggle room left for EWWW IO to work.

Also note that this only affects the scanner, and the bulk process. Actual image optimization can take (lots) more memory, and there isn't any way to prevent that. All you can do in those cases is increase the memory_limit setting in PHP. In particular, JPG resizing will tend to decompress the image, which means a 4MB JPG could take 100MB to resize when it is being resized. Another area where memory usage can increase unexpectedly is when using the API. The entire image file has to be loaded into memory when it is sent to the API, and subsequently, the optimized version has to be loaded into memory before it is written back to disk. Fortunately, it doesn't have to be decompressed during that transaction, so the memory usage is generally much lower than when image resizes are generated.