0

I've come across a few generic versions of this question asking for general comparisons between shared memory / tmpfs / mmap / block reads, but I wanted to ask an application-specific version of this question to try and figure out the more efficient approach in terms of latency.

I have bindings for an image processing library which only offers an option to write to a named file, as opposed to offering any direct-to-memory byte array options. I'm using this library as part of a server that reads source images in many different formats and sizes, applies size/color transformations, and caches the thumbnail version of this image in memory in an LRU cache. The server then serves these thumbnails out of the LRU, over http. The server will have a bounded number of image workers (say 2-4). Source images could range in average sizes of 100KB-20MB. Output image sizes could range in average of 20KB-1MB.

My previous image process library that I was using did have the ability to just write the output image to a byte array, and I am now attempting to switch to this other library. So I am evaluating my options for working around this output limitation.

I've been investigating mmap and tmpfs as options, and I have a few combinations of ideas, but based on my access patterns I am hoping to hear some informed responses regarding overhead or complications.

My concern about /dev/shm was regarding portability, since I don't want to have to configure/mount it myself for my app, and it could be a fixed size (though most likely present and plenty big). I am also not clear on what happens under the hood when a normal block-backed preallocated file in say /tmp is mmap'd and the image library writes to it, and I read back from it. Is there any benefit there on the read size of things?

Summary

Is the following potential approach to having a {file,memory}-backed image buffer an appropriate use for mmap?

  • If /dev/shm is mounted, preallocate a memory-backed file for each image worker
  • If /dev/shm is not mounted, preallocate a normal /tmp file for each image worker
  • Keep an mmap open for each worker, for the length of the server process. Output image data would get written to the file path from the image library, and then accessed through the mmap byte array to be copied in an LRU cache.
Community
  • 1
  • 1
jdi
  • 90,542
  • 19
  • 167
  • 203
  • Sorry, all I meant was that sometimes people overlook the easy solution and put hundreds of expensive engineering hours into solving a problem that a $120 SSD or an extra 16GB of RAM might solve. – Mark Setchell Jul 16 '14 at 20:14
  • Which library are you forced to use by the way? And what particular features are forcing you to use it? And what language too? – Mark Setchell Jul 16 '14 at 20:20
  • I can guarantee that this isn't a "hundreds of hours" solution. It should be a day or two of work really. But I am trying to get a clear picture of the benefits of the listed options in regards to this specific application. I'm currently using ImageMagick + OpenColorIO, but I want to switch to OpenImageIO because it reduces my library dependency, and the need to go between two librarys to do image transformations + color. And that OpenImageIO is in use at my work and has plugin support, so it would be ideal to use that as my image processing library since it will handle custom image types. – jdi Jul 16 '14 at 21:11
  • And the language this server happens to be written in is Go – jdi Jul 16 '14 at 21:12

0 Answers0