Grant Edwards wrote: > On 2007-12-25, Diez B. Roggisch <[EMAIL PROTECTED]> wrote: >> Carl K schrieb: >>> Grant Edwards wrote: >>>> On 2007-12-24, Carl K <[EMAIL PROTECTED]> wrote: >>>> >>>>>> If it is a multi page pdf Imagemagick will do: >>>>>> >>>>>> convert file.pdf page-%03d.png >>>>> I need python code to do this. It is going to be run on a >>>>> someone else's shared host web server, security and >>>>> performance is an issue. So I would rather not run stuff via >>>>> popen. >>>> Use subprocess. >>>> >>>> Trying to eliminate popen because of the overhead when running >>>> ghostscript to render PDF (I assume convert uses gs?) is about >>>> like trimming an elephants toenails to save weight. >>> maybe, but I wouldn't be so sure. >>> >>> currently the pdf is created in a python StringIO buffer and returned to >>> the browser; so it never becomes a file. using convert means I have to >>> first save it as a file, convert from file to file, read the file, >>> delete the 2 files. so 6 file operations where before there were none. >>> That may be more of a load than the ghostscript part. >> So what? I'm not sure about current HD speeds, but a couple of years ago >> these were about 30MByte/s - and should be faster today. Which equals >> 240MBit/s, much more than your user's internet connection. and this is >> raw IO speed, not counting disk caches. > > Unless the file is really huge (or the server is overloaded),
The server is already overloaded, > the bytes will probably never even hit a platter. If you're > using any even remotely modern OS, short-lived tempfiles used > as you desdcribe are basically just memory-buffers with a > filesystem API. Good point. Not that I am willing to risk it (just using the pdf is not such a bad option) but I am wondering if it would make sense to create a ramdrive for something like this. if memory is needed, swap would happen, which should be better than creating files. Carl K -- http://mail.python.org/mailman/listinfo/python-list