convert pdf to png

[Carl K]

Grant Edwards wrote:
> On 2007-12-25, Diez B. Roggisch <deets at nospam.web.de> wrote:
>> Carl K schrieb:
>>> Grant Edwards wrote:
>>>> On 2007-12-24, Carl K <carl at personnelware.com> 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