Console Screen Display Time

[Jack Kramer]

FUNCTION PBMAIN

'5.4 sec for 25,000 screen refresh using PB 3.5 For Dos
'76 sec for 25,000 screen refresh using PCcc 4.0
t1# = TIMER
DEFLNG a-z
COLOR 15,1
FOR z& = 1 TO 25000
CLS
LOCATE 10,10 : PRINT z&;" refresh event"
NEXT z&
t2# = TIMER
CLS
LOCATE 20,20 : PRINT "Refreshment Time:";t2#-t1#
WAITKEY$

END FUNCTION

During the process of converting from PB 3.5 for Dos to PBcc 4.0 a blink was most noticeable while generating a new screen display. The times for the above of 5 sec for PB 4 Dos and 76 sec for PBcc was unexpected. Should have I expected this or is my code just faulty. Your comments/suggestions are most welcome. I really don't like what what has come my way.

Thanks for all the valuable posting in the past.

Jack

[John Strasser]

I had to do some work a bunch of years ago on something similar - but that was using MFC (client spec).

The trick I used was to write the new screens to different code pages and then just switch pages within the window. I don't remember the metrics but they freaked when they saw how fast it was. Suddenly their hundred thousand $$$ machine was the bottleneck - not the control & display system <grin>.

Not sure how PBCC & the console screen work - if they use code pages or if that trick would speed things up.

When you were using PBDos was it on a DOS box? Or in the console window?

You could also try (just to test) boot into safe mode - console only and see what happens.

Just some random thoughts.

John, Hypnotherapist Extraordinaire, NLP Trainer,
and Full Time Grad Student in Clinical Psychology
---------------------------------------------------
John Strasser
Phone: 480 - 344 - 7713
http://www.inthespiritmarketing.com
http://www.lifetranscendent.com

[Mel Bishop]

The big thing slowing you down is:

CLS
LOCATE 10,10 : PRINT z&;" refresh event"

Running your example as-is took 126.4 seconds on my machine. REM'ing out only the CLS reduced the time to 21.9 seconds and REM'ing out both lnes, it took 0 (zero) seconds.

Screen updates takes a hoop of time to accomplish. It's best to avoid unnecessary updates like the plague.

[Jack Kramer]

Currently I'm using PAGE and PCOPY to make screen output appear to take less time, and it does take on an improved appearance. However, that procedure takes even longer.

Thanks for the input, Jack

[Eric Pearson]

Jack --

Which version of Windows are you running?

-- Eric

[Jack Kramer]

Win XP with PBcc 4.0 and PB 3.5 for Dos

[Peter Lameijn]

The code runs in 21 seconds on W2KSP4 with PBCC3 on an Athlon64-3200+
(In 3.2 seconds without the cls)

But what's the use anyway? If it's 3 or 100 seconds; in none of the cases you'll be capable of reading it at that speed...

If you don't need color, StdOut runs much faster:

Function PBMain
  t1# = Timer
  StdOut Chr$(10,10,10,10,10,10,10,10,10,10)
  For z& = 1 To 25000
  StdOut Space$(10) & Format$(z&) & " refresh event" & Chr$(13);
  Next z&
  t2# = Timer
  Cls
  Locate 20,20 : Print "Refreshment Time:";t2#-t1#
  WaitKey$
End Function

[Jack Kramer]

The posted code was used just to get an idea of the time required to write some additional info on an existing screen. Using PB4Dos, the task took zero time. I know it wasn't actually zero, but so quick it appeared to be so. The actual program has been running for years. Looking forward, problems just seemed to be heading our way, such as new printers. The solution appeared obvious, upgrade to PBcc. Users expected a product superior to PB4Dos version and it will be sometime. Refreshing the screen has been irritating to some. Yes, user can't read faster than it is displayed. However, users want at least what they had before this problem arose.

Thank you folks for your comments.
Jack

[Adam J. Drake]

Do you actually need to clear the screen in between each output?

That is one thing that is slowing down the first example quite a bit.

I like to use API Calls for console printing. The routine I found awhile back on the forum (not sure from who), but on my machine the following runs in 1.6 seconds (Peter's runs in .8 seconds on mine without the CLS, color adds the extra time):

DECLARE FUNCTION FillConsoleOutputAttribute LIB "KERNEL32.DLL" ALIAS "FillConsoleOutputAttribute" (BYVAL hConsoleOutput AS DWORD, BYVAL dwAttribute AS DWORD, BYVAL nLength AS DWORD, BYVAL dwWriteCoord AS DWORD, lpNumberOfAttrsWritten AS DWORD) AS LONG
DECLARE FUNCTION WriteConsoleOutputCharacter LIB "KERNEL32.DLL" ALIAS "WriteConsoleOutputCharacterA" (BYVAL hConsoleOutput AS DWORD, szCharacter AS ASCIIZ, BYVAL nLength AS LONG, BYVAL dwWriteCoord AS DWORD, lpNumberOfCharsWritten AS LONG) AS LONG

DECLARE FUNCTION GetStdHandle LIB "KERNEL32.DLL" ALIAS "GetStdHandle" (BYVAL nStdHandle AS DWORD) AS DWORD

%STD_OUTPUT_HANDLE = -11&

FUNCTION PBMAIN

'5.4 sec for 25,000 screen refresh using PB 3.5 For Dos
'76 sec for 25,000 screen refresh using PCcc 4.0
t1# = TIMER
DEFLNG a-z
COLOR 15,1
CLS
FOR z& = 1 TO 25000
CALL FastPrint(10, 10, 31, FORMAT$(z&)+" refresh event")
NEXT z&
t2# = TIMER
CLS
CALL FastPrint(20, 20, 31, "Refreshment Time:"+FORMAT$(t2#-t1#))
LOCATE 20,20 : PRINT "Refreshment Time:";t2#-t1#
WAITKEY$

END FUNCTION

SUB FastPrint (BYVAL lRow AS LONG, BYVAL lCol AS LONG, BYVAL lColor AS LONG, BYVAL lText AS STRING)
DIM hOut AS LONG

    'It starts at 0,0
    DECR lRow
    DECR lCol

    'If color < 0 use current position color
    IF lColor < 0 THEN
        lColor = SCREENATTR(lRow, lCol)
    END IF

    'Get handle
    hOut = GetStdHandle(%STD_OUTPUT_HANDLE)

    'Write text
    WriteConsoleOutputCharacter hOut, BYCOPY lText, LEN(lText), MAKDWD(lCol, lRow), 0

    'Change color
    FillConsoleOutputAttribute hOut, lColor, LEN(lText), MAKDWD(lCol, lRow), 0

END SUB

[Peter Lameijn]

Users expected a product superior to PB4Dos version and it will be sometime.

It is in all aspects except the screen speed. Because that isn't relevant, there should be no problem, and your product will be superior to the PB/Dos version.
In cases where you want to show text as you described, you can easily show item 1, 50, 100, 150, ect... an skip the items between to speed up things without anybody noticing it...

[Michel Le Gros]

Console Screen Display Time

A certain time ago, suggestions were made in this forum to define a console size of 26 lines instead of the standard 25 as to pass around some OS limitation/behavior with standard size console screen. It did accelerate things quite a bit for Win95

Cheers

[Richard Angell]

Adam's code logs in at .11 to .22 sec here depending on what else is happening in the background. But then this is on a WinME system, probably looks like a slower Greyhound on the XP system.

Seriously, use the API's as Adam has if speed is the need here ... but the point is that no one is going to read 25000 lines in even tthe slowest times posed here. So the point about displaying what is truly needed is really gemane to how one would approach the situation.

[Michael Mattias]

>if speed is the need here ...

If speed is this need, Step One is to cut out the redundant code. ... code which also results in phony timing.

While "CLS" has been pointed out as a time-waster, what about the waste in the rest of the code?

For z& = 1 To 25000
  StdOut Space$(10) & Format$(z&) & " refresh event" & Chr$(13); ' LINE OF INTEREST 
  Next z&
  t2# = Timer
  Cls
  Locate 20,20 : Print "Refreshment Time:";t2#-t1#

The line of interest is creating a new string using concatenation each time thru the loop.

Why not create the SPACE$(10), put it in the right place on the screen, then create the "refresh event" literal and put that in its correct place on the screen ONCE, before starting the loop?

Then all you have to print each time through the loop is the formatted integer in its correct place.

For each iteration of the loop that saves two string creations/modifications and three concatenations. (FWIW, concatenating CRLF appears to do nothing useful).

>but the point is that no one is going to read 25000 lines
Give that man one of the big stuffed teddy bears for his little lady friend, because he is absolutely correct. It is silly to think you need to refresh this each time through the loop because there is no way a user is can or would read it each time.

The fault, dear Brutus, is not in our stars, it is in our selves.

MCM

[Jack Kramer]

Thanks to all for your comments. Adam J. Drake, the speed of that code is amazing. There several ideas that need some attention on my part. What a wealth of info available to me is just great.

Thanks Again, see you soon
Jack