Announcement

Collapse
No announcement yet.

Console Screen Display Time

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Jack Kramer
    replied
    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

    Leave a comment:


  • Michael Mattias
    replied
    >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?
    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

    Leave a comment:


  • Richard Angell
    replied
    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.

    Leave a comment:


  • Michel Le Gros
    replied
    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

    Leave a comment:


  • Peter Lameijn
    replied
    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...

    Leave a comment:


  • Adam J. Drake
    replied
    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):

    Code:
    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
    Last edited by Adam J. Drake; 18 Feb 2008, 01:08 AM.

    Leave a comment:


  • Jack Kramer
    replied
    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

    Leave a comment:


  • Peter Lameijn
    replied
    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:
    Code:
    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
    Last edited by Peter Lameijn; 17 Feb 2008, 07:19 PM.

    Leave a comment:


  • Jack Kramer
    replied
    Win XP with PBcc 4.0 and PB 3.5 for Dos

    Leave a comment:


  • Eric Pearson
    replied
    Jack --

    Which version of Windows are you running?

    -- Eric

    Leave a comment:


  • Jack Kramer
    replied
    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

    Leave a comment:


  • Mel Bishop
    replied
    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.

    Leave a comment:


  • John Strasser
    replied
    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

    Leave a comment:


  • Jack Kramer
    started a topic Console Screen Display Time

    Console Screen Display Time

    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
Working...
X