« VDP Hall of Shame | Videos From Down Under »
Print on-Demand Solutions recently published a performance benchmark comparison on Darwin versus uDirect. This comparison study indicated that Darwin was consistently faster than uDirect across different application types and output formats; with results varying from twice as fast to over 22 times as fast, depending on the output format. I was quite surprised to learn that the performance gap between these two products was so signficant, so I decided to verify the results for myself.
I invited a representative from Print On-Demand Solutions and XMPie to attend my benchmark testing, so they could verify that the test environment was fair and my performance results were accurate.
I created four different application types and tested them across four VI output formats; VPS, PPML, PPML/VDX and VIPP. The applications varied in level of complexity, ranging from a simple mail-merge application, to a more complex applications with different business rules controlling text, image and colour objects.
The tests indicated that the results published by Print On-Demand Solutions were an accurate representation of the performance capabilities of both uDirect and Darwin software.
Although Darwin won hands-down on performance, speed should not be the sole deciding factor when choosing VDP software. It's important to remember the key differences between Darwin and uDirect. uDirect is still stronger in it's support for InDesign core features such as Transparency, Effects, Object Styles, while Darwin offers differentiation against uDirect through it's page picking ability from different InDesign documents and hot folder automation for creating print-ready files from database files.
While speed may be a bonus for Darwin, uDirect comes with it's strengths too. At the end of the day, you have to ask yourself "how important is composition speed?" Saving several seconds or even minutes in output composition shouldn't really impact your production environment — it just gives you a bit more time to take a breath, or maybe boil the kettle for your next cuppa while you charge your client for a little more time...
Posted on Thursday, 8 November 2007 at 8:48 PM | TrackBack: http://www.veedeepee.com/cgi-bin/mt-tb.cgi/50
Seen these issues for 10 years. Yes, XMPie is very slow compared with most. However the problem I think is bigger than that. Most VDP plugins (from XMPie, Designmerge, Creo etc) usually have the accelerators like ppml, vps, vipp etc are now all included, or available at a modest cost. In this respect, the software suppliers have responded well.
Unfortunately, out in the field, these enablers or 'accelerators' are very seldom used. Every site I've visited this year have only been taught by their suppliers, (be it Xerox, Canon, even XMPie themselves), to print these jobs using the PDF format. Now I realise PDF is improving all the time, but the ability of RIPs to quickly process variable PDF streams varies tremendously. I've seen one printer on a modest 1,000 record job take over an hour, yet on another device, the same PDF take just 4 minutes before the paper appeared..
The printers DFE/RIP brand, make, model and configuration is a huge factor, as it is in all VDP workflows.
Naturally the times taken using this PDf output option are typically 10-100 times worse than those in your tests. 'Simple' VDP jobs sent by InDesign/XMPie solutions that should be taking 5-10 minutes from print dialogue to the printer starting up, are instead taking hours, often crashing Macs and RIPS in the process.
As Frank Romano stated last year when discussing VDP, "the suppliers are screwing it all up". but it's worse than that, it's not just that they can't get together over standards now that we have so many), it's that even when those extras are supplied, they are not even implemented, because it's likely deemed too hard or unnecessary
In a tough marketplace where variable data printing and new, exciting cross-marketing packages like PURLs could be the savior, poor implementation and training is letting everyone down.
As Frank rightly said, if it's all too hard, we won't do it. Yes, I too blame the suppliers.
Posted by Kevin Trye on Thursday, 2 October 2008 at 6:23 AM