Resize images asynchronously #171
Conversation
| ;; detect that work was finished prematurely and restart everything somehow. | ||
| (let-values ([(proc in out err) (apply subprocess | ||
| (current-output-port) | ||
| (current-input-port) |
There was a problem hiding this comment.
You you may notice that I never explicitly close these ports, instead relying on the OS the close them once subprocess is finished. I think this should be OK.
|
I went ahead and implemented a simple process pool. Really helped to lower memory usage while retaining the faster build times (on multi-core machines). This was my first foray into concurrent Racket programming. As usual Racket seems to excel in this area and while things felt intuitive and I tried to keep things simple you may want to review the last commit more carefully. Personally I feel pretty happy with the state of things now and barring any bugs I do not see any need for more work on this feature. The |
gerdint
force-pushed
the
srcset-async
branch
from
02da369 to
16a84d0
Compare
gerdint
force-pushed
the
srcset-async
branch
from
16a84d0 to
22985b4
Compare
Add the srcset and sizes attribute to img tags whose class is 'img-responsive' or whose parent element class is 'figure' (default Markdown behavior). Each image is made avaiable in three version (roughly intended to match a mobile, 1x desktop and 2x/hi-dpi desktop clients). Images are cached in a configurable directory. In practice the above means that images in Markdown posts are made responsive by default, and for Scribble posts the "img-responsive" class can be added like so: @image["img/some-image.gif" #:style "img-responsive"] See example/.frogrc for documentation on added parameters. There are also two additional parameters controlling resized image sizes and the default size, see bottom of frog/params.rkt. Depends on ImageMagick® for size identification and scaling.
Defaults to 1.5*<number-of-cores> concurrent processes
gerdint
force-pushed
the
srcset-async
branch
from
22985b4 to
b6c8f11
Compare
|
I have spotted one issue when using this together with the Frog watch mode. Will look into it. |
Yields a 2x speed-up on my dual-core i5 machine.
However, as it stands each size of an image to be resized yields a new subprocess potentially spawning many subprocesses concurrently if the site contains a lot of images (such as my own). This increases memory usage and may therefore cause disk swapping if memory is limited. Does not seem to be a big issue on my 8GB SSD-equipped machine but I understand performance characteristics may be different on other machines.
It may perhaps be preferable to a have a job server making sure that no more than N processes are spawned concurrently. A useful but potentially conservative value for N may be the number of processor cores.
OR perhaps I'm over-engineering here. WDYT?