[reportlab-users] Image from string instead of a disk file

[Jack Wilkinson]

Thanks for the responses from both Andy & Richard.

The thought for reading the file into a string was just to save it into memory and not have to open/read/close the file multiple times.

Andy makes a valid point… I do wonder how much of my supposed I/O to disk is really being covered by Linux and just being ready from a buffer.

I may try to take one of the reports and comment out all of the file access and where the images get used and see if there’s a radical performance difference.

Lastly, (slapping head with hand), I hadn’t even thought of creating Image objects in the main_program and passing them down.   Envisioning the code in my head, that is a fairly short and easy change to things.

I appreciate what you’ve had to say and how quick you said it.

Kind Regards,
jack

From: reportlab-users [mailto:reportlab-users-bounces at lists2.reportlab.com] On Behalf Of Richard Shea
Sent: Tuesday, June 03, 2014 4:59 PM
To: reportlab-users at lists2.reportlab.com
Subject: Re: [reportlab-users] Image from string instead of a disk file

Can't you just create a set of Reportlab Image objects before creating any documents and pass those in as parameters whenever report_lab_script is called ?

Alternatively (and really in some ways equivalent just moving down an abstraction layer) before you get going you could move your graphics files off disk into memory mapped files (http://pymotw.com/2/mmap/) and instantiate image based on those.

If your four to nine graphics are different for each document neither of these are much good (unless each graphic appears multiple times within a document and even then I'm not sure that doesn't get optimised away by the PDF standard) but either way I don't see how passing them in as strings would help ?

I'm sure you have good reasons for suggesting strings but perhaps you could explain a little more ?

regards

Richard.




On Wed, Jun 4, 2014, at 08:40 AM, Jack Wilkinson wrote:

This is one of those cases where better planning in the beginning might have been a good idea.  But now we’re deep in production without resources or time to go back and work out a better solution.



Our reporting mechanism looks something like:



main_program

                result = report_lab_script(some parameters)

                back to main program that processes the result



This works well for now.  But we expect to see the quantity of data increase by major quantities.



The report_lab_script, depending on the parameters handed to it, may open and use between four and nine images each time it gets called.  (It uses the “Image” routine.) That means a lot of file I/O for each page or group of pages produced in each iteration.



I’m curious if there’s a way to read all of the images in the beginning of the main_program into strings and then just pass those strings to the report_lab_script so it doesn’t have to do the file I/O to read the files every time.  However, “Image” seems to only take a filename.



Just grasping for straws before I end-up re-writing the world.



Appreciate any thoughts…

jack



Jack Wilkinson, Programmer

Services | VPay®

P: 972.367-6622

jwilkinson at stoneeagle.com<mailto:jwilkinson at stoneeagle.com>

www.stoneeagle.com<http://www.stoneeagle.com/>

www.vpayusa.com<http://www.vpayusa.com/>



111 W. Spring Valley Rd., #100

Richardson, TX 75081


CONFIDENTIALITY NOTICE: This email, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you received this email and are not the intended recipient, please inform the sender by email reply and destroy all copies of the original message.
_______________________________________________
reportlab-users mailing list
reportlab-users at lists2.reportlab.com<mailto:reportlab-users at lists2.reportlab.com>
http://two.pairlist.net/mailman/listinfo/reportlab-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/reportlab-users/attachments/20140603/c304e7ad/attachment.html>