We've been doing some experiment with
SET REPORTBEHAVIOR 90 and discovered some noticeable slowdown in printing rather simple reports.
Here is a summary of what we found...
We have an application that we use to track our users. It also prints upgrade order blanks at the end of the year when we issue new updates for our software. For testing purposes, we printed 250 upgrade order blanks. It took over 284.469 seconds to dump this report to the print queue. This is the time that the progress bar that VFP generates is on the screen. If you look in the print queue, the printjob is 1.66 gig. No wonder it takes so long.
Using 80 report behavior, it took .901 seconds to dump to the print queue and the file size was 3.21 MB.
This doesn't begin to address the problem of how slowly the printer can process the printjob. In behavior 80 the pages flow out of the printer without any delay at all. In 90, there is perhaps a 20-30 second delay between pages.
I can't believe that with all the hype over the improvements in the report writer that no one mentioned this horrific slowdown. This is NOT what VFP built its reputation on and will certainly detract from the benefits the 90 behavior provides.
If you'd like to see what we are talking about, here is a link to a zip file that contains a very simple example using the Northwind customer file that ships with VFP9. Although the difference in printing this simple report is small, the report is only 3 pages long; however, what you will experience is just how long it takes for the printer to process the printjob. Here is the link...
It would be interesting to see how others fell about this. I've sent emails to Doug Hennig and Cathy Poutney. Both have replied as if this is not a big deal. It is to us because we seldom create reports that are only a couple of pages long. To us, this is a deal killer when it comes to using REPORTBEHAVIOR 90.
I don't get the results that you get at all.
Running your prog I get - 90 Report: 0.750 secs, 80 Report - 2.204 secs.
Your environment obviously disagrees with 90 somehow. As I said in reply to you on UT - I have live reports, many big ones, that are running with no noticeable difference. -- Jamie Osborn
You're saying that 90 runs FASTER than 80??? Are you sure you're reading the results correctly, because these values appear backwards to me. And we performed our test on state of the art equipment. Perhaps you could describe your computer equipment. Doug Hennig replied that his printer was down the hall so I'm sure by the time he got there, the report was waiting for him... especially if it was only 1 or two pages long.
Cathy Pountney and Doug Hennig confirmed our times and passed it off as not significant? I guess I would too if I only had to print 2 or 3 page reports. How realistic is that?
You need to go print a 250 page report and see if you feel the same way after waiting for nearly 5 minutes for the report to get to the print queue. Do you really think that a user will say "Wow, look how fast this program prints!" The five minutes it takes to get the report to the queue is a "pause that refreshes" compared to the 2 pages a minute it will take for the printer to process the job. Let's see, that's only 2 hours to print 250 upgrades... Try something realworld and see if you don't change your mind. --- JohnFatte', CPA
Yep - these are the results I got. And interestingly, they were to an HP 810C directly connected to the pc. I'm going to run it again tonight to make sure that I'm not mad. -- Jamie Osborn
A 1.66gb print file for 250 pages is massive. Could it be that a config setting causes the 80 version to use printer fonts etc while the 90 version is sending it as a huge postscript/graphic image?
Pausing two of the printers in my organization, and sending the reports as above, here are my times:
Printer 1 (Tektronix Phaser 850DP)
90: 737K - 1.563 seconds
80: 98.5K - 0.250 seconds
Printer 2 (HP Laserjet 5N)
90: 1.42M - 1.750 seconds
80: 86.8K - 0.238 seconds
I get similar results to yours, John. Not a big deal for 2 pages, but 200 pages with
90 behavior would choke the poorly setup NT server here. This is a big deal, and is must be as is suggested above - that the print file is being sent as an image, not as "printer commands". This could be a dealbreaker for those wanting the new printing features. -- Peter Crabtree
Here is the reason you are not getting the same results we are. We are printing using an LPT cable to a printer connected directly to our computer.
Here are some updated stats when printing a 250 page report...
Printer Connection - Version - time to render - time to print
LPT - 90 = 284.469 seconds - approx 2+ hours to print
LPT - 80 = .901 seconds - depends on speed of printer (note on mine at 35 ppm, about 7 minutes)
NETWORK PRINTER - 90 - 49.041 seconds - depends on speed of printer (but no delay in processing the print job)
NETWORK PRINTER - 80 - 1.762 seconds - depends on speed of printer (but no delay in processing the print job)
(this is printing to a shared printer attached by LPT cable to a computer in the workgroup)
WORKGROUP PRINTER - 90 - 520.218 seconds - depends on spped of printer (but no delay in processing the print job)
WORKGROUP PRINTER - 80 - 2.323 seconds - depends on spped of printer (but no delay in processing the print job)
So this becomes an issue ONLY when printing through an LPT cable to a local printer. I'm not sure about anyone else, but most of our customers use this setup rather than the network printer. --- JohnFatte', CPA
It appears we got someone's attention. See my thread on the Universal Thread and the reply from Doug Hennig.---- JohnFatte', CPA
( Topic last updated: 2005.04.13 06:43:51 PM )