Announcement

**Michael Mattias** · 29 Oct 2009, 10:42 AM

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).

**Manuel Valdes** · 29 Oct 2009, 12:36 PM

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.

**Mike Doty** · 29 Oct 2009, 02:41 PM

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?

Very fast print for pb/cc (cprint) - PowerBASIC Peer Support Community

http://www.powerbasic.com/support/pbforums/showthread.php?t=22853

PowerBASIC and related source code. Please do not post questions or discussions, just source code.

**Guest** · 29 Oct 2009, 04:12 PM

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

**Mottel Gutnick** · 1 Nov 2009, 05:24 AM

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.

**Mike Doty** · 1 Nov 2009, 08:16 AM

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

**Manuel Valdes** · 1 Nov 2009, 09:42 AM

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,

**Michael Mattias** · 1 Nov 2009, 10:09 AM

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

**Jeff Blakeney** · 1 Nov 2009, 11:46 AM

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.

**Mottel Gutnick** · 2 Nov 2009, 07:35 PM

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

**Bob Zale** · 2 Nov 2009, 10:48 PM

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.

Announcement

Slow console output

Slow console output

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment