Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Reportbehavior 90 s...l...o...w???
Message
De
13/04/2005 16:39:01
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Divers
Thread ID:
01002833
Message ID:
01004365
Vues:
20
>>Hi John,
>>
>>I ran the code that you emailed me and here's what I found. When running your sample, yes, it ran slower with the 80 setting than it did the 90 setting. However, if you swap order of your test and do the 90 first, the times vary greatly. The first time, the 90 runs faster. The second and subsequent times, the 90 runs a little slower, but not very significant.
>>
>>Another thing I noticed is that your report has the printer information saved. This can cause speed issues if the printer that is saved is not available when you print the report. That's because it tries to find that printer first. I have also seen major speed issues along these lines when on a wireless connection because it tries to search the connection for a printer and that can slow it down.
>>
>>Cathy
>>
>>
>>
>>>Hopefully, it's me, but printing the same report using 90 report behavior with the default reportlistener is dramatically SLOWER than printing the same report using 80 report behavior. Anyone offer any help or suggestions here.
>>>
>>>Here is the code differences for 80 and 90 ...
>>>
>>> WAIT WINDOW " PRESS ANY KEY TO PRINT USING 80 BEHAVIOR "
>>> REPORT FORM (lcFRX) TO PRINTER
>>>
>>>
>>> WAIT WINDOW " PRESS ANY KEY TO PRINT USING 90 BEHAVIOR "
>>> REPORT FORM (lcFRX) OBJECT TYPE 0
>>>
>>>The 90 version prints 10 times slower with a noticeable pause between each page. Total unusable.
>
>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 a network printer.

Local or Remote LPT does not have importance;
you try to exchange the two printing or the PC where you process the job.
Since every page is an 6.6MB image,
The time of press depends on the speed of the LPT and the printer's buffer,
if the buffer allow a pipeline effect, it can hide the latency time.

If you have access to a dot printer, tries with that one;
probably you will see of the smoke to exit.

Little strange. 520 seconds vs 2 seconds is OK for you ?

Not task that the VFPT can exceed this problem and continue to use the GDI+.

Fabio
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform