> As I explained elsewhere, unless you call clear-image-cache from Lisp,
> the only place we do that automatically is when the number of
> redisplay cycles since last time the image cache was cleared becomes
> greater than 101.  This, no matter how low is the value of
> image-cache-eviction-delay, it will have no effect until we've done
> 101 redisplay cycles.  And your loop above does just one.

Hmm. I saw that email, but did not understand it well. I thought that
cache clearing is triggered not later than image-cache-eviction-delay,
but can be triggered earlier if the number of cycles is more than 101...

The behaviour you describe does not follow the docstring:
> "*Maximum time* after which images are removed from the cache.
> ...
> If the cache contains
> a large number of images, the actual eviction time may be shorter.
> ...

Also, I repeated my tests manually calling image-clear-cache every Nth
image. Every invocation of image-clear-cache does reduce the memory
consumption, but there is always some residual remaining unrealeased
(see the attached images). The residual seems to scale with the number
of images in the cache before clearing.
Suggestion: we may be able to control the memory consumption if the
image-clear-cache is not only triggered by the time and display cycles,
but also by the cache size. If a variable like image-cache-max-size is
exposed to elisp, the user may be able to deal with similar memory
consumption issues just by reducing the variable value.
Though, indeed, there should be no residual memory in ideal scenario. 

Regards,
Ihor