Announcement

Collapse
No announcement yet.

Slow console output

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

  • Slow console output

    Hello everybody,

    I'm new with PB-Windows-programming. And I have a big question and I hope you can help me. I wrote a simple program like this one:

    --------------------------------------------
    DIM t AS SINGLE
    DIM i AS LONG

    t = TIMER

    CLS
    FOR i = 0 TO 1000000
    LOCATE 5,5
    PRINT STR$(i);
    NEXT

    t = TIMER - t

    PRINT "Duration (sec.): " + STR$(ROUND(t,4))

    END
    --------------------------------------------

    I compiled it with 2 different compilers:
    PB/DOS 3.2, PB/CC 5

    Then I execute both programs under WindowsXP.
    PB/DOS (not compiled, only started in the IDE) takes about 0.9 secondes.
    PB/CC-compiled EXE takes about 47 secondes.

    I searched the PB-forum and then I found the Thread 15425:
    If I replace the LOCATE and PRINT statements by the Function FPrint (please see the thread 15425: http://www.powerbasic.com/support/pb...ad.php?t=15425), which uses API-statements, then the PB/CC-exe speeds up to about 18.5 seconds. Very nice (it's faster for three times), but why? And why isn't it so fast like the DOS-version with the PRINT-commands? I don't know, if there are any disadvantages of using the API-calls instead of the PB-PRINT-commands?

    So finally my big question is: why are Windows-console-applications sooooooooooo slowly in printing text on the console. And why are DOS-applications soooo fast?! I can't understand it.
    And: do you know a solution, how to accelerate the console-output in PB/CC-programs to the DOS-speed? Is there any possibility or is it a Windows-bug?

    Thank you very much in advance!

    Nice greetings,
    Max

  • #2
    So finally my big question is: why are Windows-console-applications sooooooooooo slowly in printing text on the console. And why are DOS-applications soooo fast?! I can't understand it.
    And: do you know a solution, how to accelerate the console-output in PB/CC-programs to the DOS-speed? Is there any
    No bugs. The console works as designed. However, everything is GRAPHIC under Windows. A fairer comparison to your MS-DOS program would be to throw your MS-DOS screen into one of the graphics modes, then scrolll up text lines using the appropriate MS-DOS grarhics commands (which I never really knew but surely would have forgotten by now anyway.)

    New operating system ==> new way of thinking ==> new application designs.

    Maybe this would be an acceptable replacement for a zillion lines of text output?
    Progress Bar Dialog for PB/CC programs October 24, 2002

    MCM
    (BTW, I almost never use the word "easy" but this progress bar really is).
    Michael Mattias
    Tal Systems Inc. (retired)
    Racine WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      In my Office's PC the same test gives .9 running in a PBDOS console, 1.9 in full screen PBDOS, and 34.3 in PBDOS Graphic mode (Screen 12).

      However, the figure for PBDOS console is tricky, since the digits are displayed sparsely, instead of progressively.

      I think it's apparent that the bottleneck is the graphic system.

      Comment


      • #4
        The size of the console window (and the buffer for each active page) is changed to the rows
        and columns specified. It should be noted that, when using Windows 95/98/ME, a change in the
        number of rows to a non-standard value (other than 25, 43, 60) will substantially increase
        the execution speed of PRINT statements.
        Have you tried this cprint?
        http://www.powerbasic.com/support/pb...ad.php?t=22853
        How long is an idea? Write it down.

        Comment


        • #5
          At first, I want to thank you so much for your responses!!

          @Michael: I know, what you mean: a graphical text-output is of course not so fast like a real text-mode-output. You are right! But the PB/DOS-Output was a graphic-output too, because my test-application ran in Window-Mode and not in full-screen. And If I execute my PB/CC-application in a full-screen-window, then it is still slowly.
          The progressbar is very nice, but nevertheless it doesn't help me. I'm writing an application, which calculates the real-time-coordinates and ephemerides of the sun/moon/planets. And so I have a lot of outputs per second. But if the output is so slowly, then it delays all calculations. :-(

          @Manuel: You are right: the digits are display sparsely. But it is very fast! And it would be ok for my application because if I switch in full-screen, then the output is ok again.

          @Mike: nevertheless the it doesn't work. But I read in an article, that this problem was solved in WindowsXP and your advice only works in Win95/98/ME.

          Like Manuel wrote: the PB/DOS in window-mode displays the digits of my numbers sparsely. Ok in the moment it is not possible to get a quicker graphic-output like this one. So we cannot see always all digits, but the application itself is executed very quickly.
          But the PB/CC-application is delayed because of the output. And that's the main-problem, I think. Does anyone have an additional idea?
          I think, it's very sad, because the calculation- and execution-power of PB/CC is much decreased because of this. :-(

          Thank you all again in advance!
          Nice greetings,
          Max

          Comment


          • #6
            Originally posted by Michael Mattias View Post
            ... However, everything is GRAPHIC under Windows.
            But so is DOS under Windows -- assuming the program is being run in a windowed command-prompt window as opposed to hardware full-screen mode (which is not possible in post XP versions of Windows). If that's how he's running it then it IS a fair comparison.

            Is that how you were running your DOS program, Max (and what OS version are you running it on)?

            I must say, I too have noticed a similar difference in speed when comparing a DOS program run in a (non full-screen) command-prompt window with a Windows console app doing similar screen output under Windows XP.

            ADDENDUM:

            Whoops, just noticed. They are running under XP, and the DOS version is running in the IDE (presumably windowed). Not absolutely sure of this, but I would guess that a compiled exe would be faster still, even when windowed.
            Last edited by Mottel Gutnick; 1 Nov 2009, 06:45 AM.

            Comment


            • #7
              Not sure what you mean by doesn't work since cprint is at least 3 times faster than print.
              Can you adjust the screen updates by using a duration& instead of updating it a million times?

              Code:
              %DoesNotWork = 1
              #COMPILE EXE
              #DIM ALL
              #INCLUDE "win32api.inc"
              UNION window_size
                wdw AS DWORD
                wco AS coord
              END UNION
              FUNCTION PBMAIN () AS LONG
                DIM t AS SINGLE
                DIM i AS LONG
                DIM  maximum AS LONG
                DIM duration AS LONG
                maximum = 1000000
                duration = 1000
                t = TIMER
                COLOR 7,1,1
                CLS
                FOR i = 0 TO maximum
                  #IF %DoesNotWork = 1
                  IF i MOD duration = 0 THEN
                    Cprint 5,5,STR$(i),23
                  END IF
                  #ELSE
                  IF i MOD duration = 0 THEN
                    LOCATE 5,5
                    PRINT STR$(i);
                  END IF
                  #ENDIF
               NEXT
                LOCATE 5,5:PRINT STR$(maximum)
                t = TIMER - t
               PRINT "Duration (sec.): " + STR$(ROUND(t,4))
               WAITKEY$
              END FUNCTION
              SUB cprint (BYVAL row&, BYVAL col&, BYVAL text$, BYVAL tatrib&)
                LOCAL posn AS window_size, _
                              buff AS ASCIIZ * 81,_
                              hand AS LONG,_
                              tlen AS LONG, _
                              nos  AS LONG
                posn.wco.x = col& - 1
                posn.wco.y = row& - 1
                buff = text$
                tlen = LEN(text$)
                hand = GETSTDOUT
                CALL writeconsoleoutputcharacter (hand, buff, tlen, BYVAL posn.wdw, nos)
                CALL fillconsoleoutputattribute (hand, tatrib&, tlen, BYVAL posn.wdw, nos)
              END SUB
              How long is an idea? Write it down.

              Comment


              • #8
                Max:

                In case your program does a lot of calculation, which can then be displayed in the screen, a good strategy is to first store in memory the results, and then display the full set in a single command or procedure. In this type of applications I have found that PBCC in graphic mode (GRAPHIC WINDOW) if faster than the "Text" mode, provided you use the REDRAW option for the graphic window. What I know about the graphic system is that every time a program modify even a single pixel, the entire screen is updated. This causes it to slug when displaying a single field of digits changing faster than the graphic system is able to handle. There are some very fast graphic systems, but in general quite expensive.

                Best regards,

                Comment


                • #9
                  which calculates the real-time-coordinates and ephemerides of the sun/moon/planets. And so I have a lot of outputs per second
                  Well, I think this is the fly in the ointment. Who can read that fast anyway? And frankly, if anyone cares about the 'intermediate' results your application should be storing them in a file, where you can write them a heck of a lot faster than you can display them on a screen using ANY method.

                  Mr. Doty has started you down what I believe to be a superior design path. Follow him.

                  MCM
                  Michael Mattias
                  Tal Systems Inc. (retired)
                  Racine WI USA
                  [email protected]
                  http://www.talsystems.com

                  Comment


                  • #10
                    Originally posted by Mottel Gutnick View Post
                    But so is DOS under Windows -- assuming the program is being run in a windowed command-prompt window as opposed to hardware full-screen mode (which is not possible in post XP versions of Windows). If that's how he's running it then it IS a fair comparison.

                    Is that how you were running your DOS program, Max (and what OS version are you running it on)?

                    I must say, I too have noticed a similar difference in speed when comparing a DOS program run in a (non full-screen) command-prompt window with a Windows console app doing similar screen output under Windows XP.
                    I'm not 100% sure aboiut this but because DOS programs are writing to their own screen memory and not sending data directly to the command prompt's console window, I think the command prompt window copies data from the DOS screen memory to itself whenever it can. This means that the DOS program never has to wait for the screen to update before moving on in the code. With a program printing line after line of data, you will probably see a particular line jumping multiple lines at a time up the window instead of going up one line at a time. You might only see a line appear once and some lines may not appear at all depending on how fast the code is running and how often the window gets updated.

                    With a PBCC program you will probably see every update appear and scroll up each line because the PRINT statement won't return to your program until after it has drawn the text in the console window.

                    I ran into this sort of thing when I wrote a dialog I could include in projects that would display one or more progress bars so I could give users feedback on how long something was going to take. When I first wrote it, it slowed my programs to a crawl. The problem was that I was redrawing the progress bar even when the position change sent in would have resulted in no visual change to the progress bar. I then modified this code so that I first checked to see if the update would result in a visual change to the progress bar and if it didn't, I would immediately return. It was the updating of the progress bar that was slowing down my program just like the updating of the console window is slowing down the PBCC program in this case.

                    You could, if you really wanted, simulate the way DOS programs in a command prompt window work in your PBCC programs by creating your own screen memory and make your own print command to put data there and have a separate thread that copies this data to a console window whenever it has a chance. However, it is probably easier just to not do things that require updating the console window and scrolling it a million times.
                    Jeff Blakeney

                    Comment


                    • #11
                      > I'm writing an application, which calculates the real-time-coordinates and ephemerides of the sun/moon/planets.

                      Max, (This is slightly off topic, but) I'm very interested in this. Are you interested in positional astronomy personally or academically? If so, would you mind taking occasional questions on the subject (by PM -- or perhaps you or I could start a suitable thread about it in the Cafe PB forum). I have a 'hobbyist' interest in it, but not a great deal of expertise on the subject.

                      If it's any help, (though I'm sure you must know of these already) -- look for books by (Jan?) Meeus, and Peter Duffet-Smith.

                      Comment


                      • #12
                        The Windows Console Device is considerably slower to display than a DOS screen for a variety of reasons---

                        1- In DOS, PowerBASIC can write directly to the memory of the video card. That's impossible in a protected mode, Windowed environment.

                        2- The console must serve not just one program, but potentially many applications simultaneously. It "seems" as though earlier versions of Windows delayed display to accumulate numerous lines of data to display them all at once. This has been improved over time, but the reasons are still reasonably valid. For example, type DIR on a huge directory (hundreds of files), then immediately start typing a new command. Your new command won't even start to display until the directory listing is complete.

                        3- There are more, but they aren't worth worrying about because we can't change any of them. They were implemented by MS for what they thought was a good reason and we're stuck with them, like it or not.

                        What can you do to speed things up?

                        1- PowerBASIC uses the WriteConsoleOutput API for the PRINT statement. It is slower than some other methods, but it is the most accurate. Other API's have the nasty habit of changing text foreground and background colors randomly (a few characters at a time) with some Win versions. If you can live with that, there are a number of other choices. In fact, the PowerBASIC STDOUT function uses WriteFile, and that can be faster, even if not totally accurate.

                        2- Using a non-standard console size can help, particularly with Win95/Win98/WinME.

                        4- The best alternative is to aggregate your console data, and write it all at once. Use the PAGE statement to PRINT all your data to another screen which is not visible. After you're done, make that page your visible page. This is the quickest, and most accurate methodology. It gives the appearance of being instantaneous.

                        5- The worst thing you can do is to PRINT text a few bytes at a time or a few words at a time.

                        Best of luck!

                        Bob Zale
                        PowerBASIC Inc.

                        Comment

                        Working...
                        X