Jump to content

Compose speed issue


ericg

Recommended Posts

Hi this is my first post so i'll to do it correctly. I am also new to fusion pro.

 

I have a 4x6 postcard that i have to compose many times per day with different data on it each time. right now all the variable information is in one file, delivery names and addresses, text to printed on the left, path to front photo, path to back photos, etc... With the exception of the delivery names and address, all the other data is repeated for each record. I have been testing this for a few days now and have been getting speeds of only approx .5 rec/sec for about 500 recs and approx .2 rec/sec for larger files (about 1000 recs). In one case i had 2400 records and it took almost 6 hours to Compose. As i said earlier the photo on the front is variable and quite large, aprox 22 MB EPS but i think Fusion pro is converting it to a PDF of about 8 MB when i start the compose. There are a couple of other variable graphics on the back but they only about 22 K or so. All total i have probably about 9 variable text boxes and 3 variable picture boxes.

 

My mac is a G5 2x2.66Ghz Dual-Core Intel Xeon with 2 GB 667Mhz DDR2 FB-DIMM OS is 10.5.6 Adobe Acrobat 8.1.3 Fusion Pro 5

 

So finally my question is: Is the best speeds i'm going to see for this or does anyone have an suggestions about speeding it up? Any help would be appreciated. Thanks, Eric

Link to comment
Share on other sites

Eric, try temporarily removing the large image from the job and time some compositions. If they are much faster than you can work on optimizing that image.

 

I have tried that and it doesn't make any difference. I just ran it with it variably swapping in a 76K PDF for the front photo, it still only got .66 rec/ sec for only 1000 records. I've also tried just having a static front photo and that still makes a negligible difference. I've moved all the variable graphics and things locally so i know its not a network issue. I've also just recently started using two files one for all the names and the other for just the variable information (pictures, text, etc) so that Fusion Pro doesn't have to parse the 1 large datafile with all the variable info repeated in each record...but again, that doesn't seem to make a difference. Any other suggestions?

Link to comment
Share on other sites

Aaron,

 

The DEF file should not normally get to be this large considering it is a text data file and has a limited amount of information for most templates (field names, resource references, and rule content).

 

However, you may be seeing a bug that we addressed in 5.1P2c last year where DEF files (and the FusionPro PDF template which contains this DEF data) grew in size when templated rules are being used.

 

This was only an issue with 5.1P2b on the Mac so if you are running this version, please upgrade to 5.1P2c or later (5.8 or 6.0).

 

Additional details about this are on the version history page:

http://www.printable.com/FusionPro-VDP-version-history/

 

hth

Link to comment
Share on other sites

I think i got it figured out. it wasn't the big graphic at all that was causing the problem. It was actually the way i was calculating the recordcount to determine which indicia graphic to use. I had a rule to display the correct indicia based on the number of records in the data file. Well, it was trying to calculate it for every record. So i created a global variable called rCount. Then i set rCount to the recordcount in the OnJobStart rule. Then i just checked the value of rCount in the indicia graphic rule and now all runs well. I am getting about 7 records per second now instead of the .3 i was getting earlier. Thanks for your suggestions guys.
Link to comment
Share on other sites

Hello,

 

Good to hear you found the issue.

 

This is a really good point for other users who may be experiencing speed issues - if you only have to run a script once per job (versus every record), put that logic in an OnJobStart rule.

 

I remember another customer job where they were using an external data file to do a cross-reference lookup from their input data to a second data source. In their logic, they created a reference to the external data file at the beginning of every record where they only needed to do it once - at the beginning of the job. Moving this logic from an OnRecordStart rule to the OnJobStart rule resulted in a dramatic composition speed increase.

 

I guess one way to think about this is that our composition process is optimized (we only process each image 1 time for a given composition - regardless of how many records that image appears in), the output is optimized (each image is in the output file only once and then referenced as many times is needed throughout the printstream), but it's up to the template designer to ensure that their logic is also optimized so a particular script isn't run more times than is needed for a given composition.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...