Composition Speed

[jurgmay]

Hi all,

I have a query and wonder if people are getting similar results...

We have a job coming up in the next few weeks which require 40,000 records to be overprinted onto pre-printed paper. The data is simply name and address plus a unique ID number. There are no JavaScript rules, no resources being used and no background image on the PDF. All we have is a blank PDF with a few FP boxes drawn with fields imported.

I've just run a test on the first 2,000 records using the data from the last time we ran this job and it took an average of 160 records per minute. This will take over 4 hours to process.

What I'm struggling to understand is how Microsoft Word, on the same PC, can process the entire 40,000 records is just 5 minutes. To me this doesn't make too much sense.

I'm looking to overhaul our systems to ensure that we run a PDF based workflow and therefore would like to use FusionPro to do the composition of variable data jobs but it's incredibly hard to justify on the back of results like this...

I'm guessing that the cost of FP Direct or FP Server is going to be far more than I can justify, though I'm waiting to hear back on that.

Really what I'd like to know is whether people are getting similar composition speeds to what I described above - 160 records per minute.

The PC I'm using is an HP, 2.4Ghz, 2Gb RAM.

Any feedback appreciated.

Thanks,

Juerg

[Alex Marshall]

Hello Juerg,
The answer to why a job takes a certain amount of time to compose is, it
depends. There are a lot of factors that go into determining how long
it takes to compose a record of data. Some of the main ones are: the
number of pages and frames in your job, the number and size of external
resources (graphics), the location of external resources (local vs. from
a network), the number and complexity of JavaScript rules (especially
things like text measurement or copyfitting which make multiple passes),
the output format, use of output chunking or imposition, and the
capabilities of your computer, including CPU speed, memory, and disk
space. Also, if you're currently using FusionPro Desktop, you may see
better composition times from FusionPro Server for certain jobs.

Analyzing why your particular job seems to take a long time to compose
would require looking at it, which I can't really do in the context of
the forum. It's possible that there are things which could be done to
make it more efficient. If you're utilizing the Page Usage feature,
you're composing every page for each record, whether you're using it in
the output or not, so you might be able to optimize the job by putting
the variable info onto a single page and only composing the parts you're
using. Also, if you're using barcodes, you might be able to minimize
the number of times you're calculating the barcode data, especially if
you're encoding the same data multiple times. But again, a full
analysis and optimization of the job is beyond the scope of this forum.

As to the relative composition speed of FusionPro versus other VDP
products as well as Mircrosoft Word, I don't know how all those other products work, especially for generating variable data, so I can't really speak to that, although I don't know if they have the same capabilities and features of our program.

Hope this information helps.

[jurgmay]

Hi Alex,

Thanks for your reply.

As I mentioned in my post, the job in question is simply two FP frames. One with name and address fields (five in total) and one containing an ID field. There are no rules, calculations, resources, page usage, JavaScript or anything else being used - it's just 6 fields inserted into an entirely blank PDF. The only things to process are the address and ID data, no images, no additional text data. I can't envisage many real-life examples that could possibly be simpler than this...

I must admit that I'm a little frustrated that you don't seem to have read my post at all and seem to have posted a stock reply, variations of which I've seen on this forum when similar questions have been raised. I quite agree with all your comments but they simply don't relate to what I posted?!

I'm not sure whether any of this leaves me more or less frustrated than I was before but thanks for your input anyway.

Regards,

Juerg

[MartyrSyx]

Hi Juerg,

I've wondered about the speed difference between word and fusionpro desktop too when doing just an address block. We still use word for many documents that we can because of it. I did 2 tests to give you another speed comparison. I have a pretty complex job in that it has an external data file with several javascript rules. It was coming out at about 160 per minute. I then removed all but 2 of the text frames on the two pages and all of the rules. It composed at about 500 per minutes. My PC specs should be in my signature. This was actually run on the "c" version of FusionPro 7.0 but the speeds of prior versions weren't much faster.

[jurgmay]

Hi Brad,

Thanks for you reply, that's very interesting. I've tried on various PCs in the building and they all average around the 160 mark, even though it's a basic job but you seem to be seeing results much better than this.

I wonder whether the version of Acrobat makes a difference as I'm only on version 7. I'm also running FP 7.0c, though only a demo version but I get identical results on 6.2.

I find it bizarre that people are resorting to Word for mail merging address data when software as powerful as FP should seemingly be superior. Printable always seem very defensive when this subject is raised (search the forums) and indeed I even had a private, off forum message from them. Quite why they won't talk openly I don't know...

[esmith]

Originally Posted by jurgmay

I find it bizarre that people are resorting to Word for mail merging address data when software as powerful as FP should seemingly be superior.

While Word may be a claw hammer to FP's pneumatic nail gun comparison, the fact of the matter is that one should always choose the right tool for the job. I don't necessarily agree that the more powerful tool should always be the "go to" tool.

[jurgmay]

Originally Posted by esmith

While Word may be a claw hammer to FP's pneumatic nail gun comparison, the fact of the matter is that one should always choose the right tool for the job. I don't necessarily agree that the more powerful tool should always be the "go to" tool.

I agree to a certain extent but would you REALLY merge 40,000 records in Word? Our requirement is that it needs to be chunked in 500s so to do this in Word is pretty much a manual process with the operator having to ensure they merge the correct record range and name the file correctly. To me, FP is the best tool for the job - perhaps just not the quickest...

I can live with the speed thing (or lack of in my case!) - I just wanted feedback from other users to see if 160 records per minute is par for the course.

[david]

Just did my own experiment. My document (no rules, usage, etc.) had three FP boxes: name & address, IMB, sequence number. We have FP Direct so I composed using that, as well as locally. Locally, I saw about 250 records per minute. With FP Direct it was 3,000 records per minute.

[jurgmay]

Originally Posted by david

Just did my own experiment. My document (no rules, usage, etc.) had three FP boxes: name & address, IMB, sequence number. We have FP Direct so I composed using that, as well as locally. Locally, I saw about 250 records per minute. With FP Direct it was 3,000 records per minute.

Wow, that's an incredible difference! I didn't expect Direct to be THAT much faster... Thanks so much for the info.

I've had pricing on FP Direct and for that level of performance it suddenly looks a much more attractive proposition.

Thanks again,

Juerg

[david]

Glad to help. The other nice thing about Direct is that it frees up your computer because the composing is transferred to the server. I'm not sure what the specs on our server are (I'm sure that's a factor), but could find out if that would help. Just let me know...