I've tried to count how many CPU cycles it takes to display 100
formatted numbers to the screen console.
Well it takes about 7 millions CPU cycles, and I think that's too
much.
Attached the program that uses loc and print to display
the 100 DW numbers after the formatting process.
Any idea to cut down this elapsed time?
you can write directly to the screen buffer
you have done that before
Quote from: dedndave on January 15, 2013, 12:00:55 PM
you can write directly to the screen buffer
you have done that before
Yes Dave, I did it, but
print uses
WriteConsole as well,
so for the time being I can only think about doing all the prints on the
buffer and display the whole buffer after that.
I don't know however if there will be a gain in performance.
i would imagine using WriteConsoleOutput would be faster
it's like accessing the console screen buffer directly as a file
in 16-bit code, we used to access the memory directly
don't guess there is a way to do that with win32
EDIT....
however, the console display area is actually a window
if you want to manage the display buffer memory yourself, you can draw characters youself
but - when you are all done getting that to work, it's still a console app :P
if you want more speed - GUI app - draw your own characters :t
here - play with this :biggrin:
i measure about 9000 characters per second
that's on a 3 gHz prescott
Quote from: dedndave on January 15, 2013, 01:14:18 PM
here - play with this :biggrin:
i measure about 9000 characters per second
that's on a 3 gHz prescott
What API did you use for that? The source is a bit confusing, there is
a lot of unused stuff inside.
Quote from: frktons on January 15, 2013, 11:41:27 AMWell it takes about 7 millions CPU cycles, and I think that's too
much.
don't worry, your CPU does approximately 10^9 cycles per second - should be enough for user I/O :P
(you will get better result by redirecting the output to a file)
as i recall, i used ExtTextOut
not sure what you mean by "unused stuff" - lol
the EXE is only 16 kb
actually - i wasn't really trying to make it super-fast
the dTxtOut proc is used to put text into the buffer
Quote from: qWord on January 15, 2013, 01:35:48 PM
don't worry, your CPU does approximately 10^9 cycles per second - should be enough for user I/O :P
(you will get better result by redirecting the output to a file)
What do you mean "redirecting the output to a file"?
I just want to display some stuff on the screen console,
how do I do that using a file?
And why should it be faster?
Quote from: dedndave on January 15, 2013, 01:36:41 PM
as i recall, i used ExtTextOut
not sure what you mean by "unused stuff" - lol
the EXE is only 16 kb
I mean when I run the prog I see a console and some stuff that cycling is displayed
on it, after that it stops.
So I don't understand what is, for example, this stuff:
;test data
TxtBuf db BUFFER_COLUMNS dup(0),13,10,0
teststr db '123456789 ',0
thrdend db -1
thrdended db -1
testcnt dd 8
;## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ##
.DATA
ALIGN 4
FeCount dd FeList
wrUpdate dd wrUpd
WheelVect dd WvNrm,WvShf,WvCtl,WhNrm,WhShf
WheelPtrs dd ShftVrtState,CtrlVrtState,HrzState,ShftHrzState
CmdVectUsr dd dCC_Acknowledge,dCC_Continue,dCC_Flush
CmdVectPma dd dCC_Acknowledge,dCC_Continue,dCC_Flush,dCP_Print
ams AppModeStruct <0,dCU_Base,dCU_MaxCmd,CmdVectUsr,AppNameUsr,dCP_Base,dCP_MaxCmd,CmdVectPma,AppNamePma>
; hRcvr dd ?
; nBaseCmd dd dCU_Base ;dCU_Base or dCP_Base (equates)
; nMaxCmd dd dCU_MaxCmd ;dCU_MaxCmd or dCP_MaxCmd (equates)
; lpCmdVect dd CmdVectUsr ;command dispatch vector table
; AppNamePtr dd AppNameUsr ;pointer to AppName string
; nPmaBaseCmd dd dCP_Base
; nPmaMaxCmd dd dCP_MaxCmd
; lpPmaCmdVect dd CmdVectPma
; PmaAppNamePtr dd AppNamePma
vs ViewSettings <0,WINDOW_HEIGHT,80Ch,BACK_COLOR,FORE_COLOR>
; WndWidth dd 0 ;default filled in at init
; WndHeight dd WINDOW_HEIGHT
; DefaultTextSize dd 80Ch ;default = 8x12
; BackColor dd BACK_COLOR ;background color
; ForeColor dd FORE_COLOR ;foreground color
CustomColors ColorStruct <MyBlack_0,MyBlue_1,MyGreen_2,MyCyan_3,\
MyRed_4,MyMagenta_5,MyAmber_6,MyLtGrey_7,\
MyGrey_8,MyLtBlue_9,MyLtGreen_A,MyLtCyan_B,\
MyLtRed_C,MyLtMagenta_D,MyYellow_E,MyWhite_F>
WinCreateTable dd WS_CHILD or WS_VISIBLE or SBARS_SIZEGRIP,StatusClass
dd WS_CHILD or SBS_HORZ,ScrollClass
dd WS_CHILD or SBS_VERT,ScrollClass
dd WS_CHILD or SBS_SIZEBOX,ScrollClass
dd WS_CHILD or SBS_SIZEGRIP,ScrollClass
dd WS_CHILD or WS_VISIBLE,TxtClass
;main menu table - item qty, [each item: (lpNewItem,uIDNewItem,uFlags)], menu title
MenuTable dd 3 ;'File' menu
dd szSaveAs,IDM_FILE_SAVEAS,MF_GRAYED ;'Save As...'
dd NULL,NULL,MF_SEPARATOR ;MFT_SEPARATOR
dd szExit,IDM_FILE_EXIT,MF_STRING ;'Exit'
dd szFileMenu ;'File'
dd 2 ;'Edit' menu
dd szCopyAll,IDM_EDIT_COPYALL,MF_GRAYED ;'Copy All'
dd szCopyForum,IDM_EDIT_COPYFORUM,MF_GRAYED ;'Copy Forum'
dd szEditMenu ;'Edit'
dd 5 ;'View' menu
dd szForeColor,IDM_FORE_COLOR,MF_STRING ;'Foreground Color'
dd szBackColor,IDM_BACK_COLOR,MF_STRING ;'Background Color'
dd NULL,NULL,MF_SEPARATOR ;MFT_SEPARATOR
dd NULL,NULL,MF_SEPARATOR ;MFT_SEPARATOR
dd szStatusBar,IDM_VIEW_STATUSBAR
StbState dd STATUS_BAR ;'Status Bar'
dd szViewMenu ;'View'
dd 3 ;'Help' menu
dd szHelpMenu,IDM_HELP_HELP,MF_STRING ;'Help'
dd NULL,NULL,MF_SEPARATOR ;MFT_SEPARATOR
dd szAbout,IDM_HELP_ABOUT,MF_STRING ;'About'
dd szHelpMenu ;'Help'
dd 2 ;'Reset Colors' submenu
dd szCustomFore,IDM_VIEW_RESETFORE,MF_STRING ;'Custom Foreground Colors'
dd szCustomBack,IDM_VIEW_RESETBACK,MF_STRING ;'Custom Background Colors'
dd szReset ;'Reset Colors'
dd 5 ;'Mouse Wheel' submenu
dd szShftVert,IDM_VIEW_MWSHFTVRT
ShftVrtState dd MF_CHECKED ;'Shft Vert'
dd szCtrlVert,IDM_VIEW_MWCTRLVRT
CtrlVrtState dd MF_CHECKED ;'Ctrl Vert'
dd NULL,NULL,MF_SEPARATOR ;MFT_SEPARATOR
dd szHorz,IDM_VIEW_MWHRZ
HrzState dd MF_CHECKED ;'Horz'
dd szShftHorz,IDM_VIEW_MWSHFTHRZ
ShftHrzState dd MF_CHECKED ;'Shft Horz'
dd szWheel ;'Mouse Wheel'
szFileMenu db 'File',0
szEditMenu db 'Edit',0
szViewMenu db 'View',0
szHelpMenu db 'Help',0
szSaveAs db 'Save As...',0
szExit db 'Exit',0
szCopyAll db 'Copy All',0
szCopyForum db 'Copy Forum',0
szForeColor db 'Foreground Color',0
szBackColor db 'Background Color',0
szStatusBar db 'Status Bar',0
szAbout db 'About',0
szTextSize db 'Text Size',0
szCustomFore db 'Custom Foreground Colors',0
szCustomBack db 'Custom Background Colors',0
szReset db 'Reset Colors',0
szVert db 'Vert',0
szShftVert db 'Shft Vert',0
szCtrlVert db 'Ctrl Vert',0
szHorz db 'Horizontal',0
szShftHorz db 'Shft Horz',0
szWheel db 'Mouse Wheel',0
WndClass db 'dTestClass',0
TxtClass db 'dTestText',0
ScrollClass db 'ScrollBar',0
StatusClass db 'msctls_statusbar32',0
AppNameUsr db 'dTest User Mode',0
AppNamePma db 'dTest Presentation Mode',0
AboutText db 'dTest',10
db 'Copyright ',169,' 2011 David R. Sheldon'
NullStr db 0
FileTypeStrs db 'Text Files',0,'*.txt',0,'All Files',0,'*.*',0,0
IccErrText db 'InitCommonControls Failed',0
AllocErrText db 'Heap Allocation Error',0
szExists db 'File Already Exists',0
szAppend db 'Append',0
szOverwrite db 'Overwrite',0
szVerify db 'Are You sure ?',0
szYes db 'Yes',0
FileErrTitle db 'Error Writing File',0
FileErrText db 'Select a different file name and/or location and try again',0
CbErrTitle db 'Error Copying to Clipboard',0
CbErrText db 'Close any programs that may be using the clipboard and try again',0
HelpText db 'Help is on the way! ;)',0
szDateFormat db "d'-'MMM'-'yyyy",0
PmaErrText db 'Unable to Open Presentation Manager Application',0
OK Dave, I've seen, this is a Win App, not a console one.
In my first impression it is quite slow during the display.
I'll build something faster and show you the difference in a
few days, maybe 400,000 chars per second.
redirecting to a file....
C:\> ExeProgram >temp.txt
the output goes to a file
it can also be done using a pipe
in fact, i would guess CMD.EXE uses a pipe to redirect
you can redirect input, as well
C:\> ExeProgram <input.txt
you could create a pipe to put things on the console screen, but i don't see that that would be fast
another example of a redirecting through a pipe
C:\> type input.txt | sort.exe >output.txt
i don't think ms provides sort.exe any more, but it used to be a DOS filter
Quote from: dedndave on January 15, 2013, 01:47:47 PM
redirecting to a file....
C:\> ExeProgram >temp.txt
the output goes to a file
it can also be done using a pipe
Why should I use this method to display stuff? I don't understand. :icon_rolleyes:
Let's say I'm scanning a data base, and each time I press a key or click "Next" I
display next dbrecord, this is what I mean display some stuff on the screen, and
redirecting to a file is not at all comfortable.
well - qWord was just saying it's faster :biggrin:
400,000 chars per second - i am waiting to see that :eusa_snooty:
at least - not into a scrollable buffer like my little demo program
notice - when that is done running, you can scroll through all 775 lines of text
i used a loop of 1000 passes, 62 chars per pass
i could blast the whole thing in there at once if i really wanted to test it
the loop is in UserCode.inc
Quote from: dedndave on January 15, 2013, 01:53:23 PM
well - qWord was just saying it's faster :biggrin:
400,000 chars per second - i am waiting to see that :eusa_snooty:
at least - not into a scrollable buffer like my little demo program
notice - when that is done running, you can scroll through all 775 lines of text
Well, that's a challenge. I get it.
First I'm going to display 400,000 chars in about 1 second in a fixed screen,
and after I'll do the same for a scrollable one.
Not an easy task, but I think it is doable, both ways.
Just wait some days.... :P
well - i am not claiming mine is all that fast - lol
it expands tabs, handles carriage return/line feed, line-wrap, vertical and horizontal scrolling, etc
as it is, it is running in "full auto update" mode
meaning that each call to put something into the buffer updates the display
i also provide for semi-auto update mode
it only updates the display if you clear a line or cause a new line/line wrap
and manual update mode - where you have to update it, yourself :P
of the three modes, full auto is the slowest
Well your app does a lot of things, and is best suited for displaying
long text files. What I'm going to do is something completely different,
so we cannot compare the two. But I need something faster than loc
and print so that's my goal for the time being.
Now I'm going to sleep, :dazzled: tomorrow maybe I'll start coding.
i didn't even think about it - lol
that thing is sending text across WM_COPYDATA to the other window :lol:
change the UserCode.inc file like this....
UsrCode PROC
push edi
mov edi,1000
loop00:
uPrint chr$('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789')
dec edi
jnz loop00
pop edi
call TestComplete
ret
UsrCode ENDP
(notice uPrint instead of dPrint)
it's about twice as fast - 18000 chars per second
Quote from: dedndave on January 15, 2013, 02:50:40 PM
it's about twice as fast - 18000 chars per second
That's a good gain. I have to admit that my preliminary tests give me a rate of
about 4 millions chars per second. But you know... :P
My PC is a Core Duo, 3-4 light years younger and faster than yours. :lol:
call Display4HT ?
OK, I have modified the prog to display 4 million chars on the
console screen, and it takes a little bit more than 1 second.
Attached the version with CALL Display4M
3e9 cycles here :t
Now you need to add scrolling, too...
Quote from: jj2007 on January 16, 2013, 12:39:02 AM
3e9 cycles here :t
Now you need to add scrolling, too...
I guess
3e9 cycles means 3*10^9 = 3 billions = 3 Ghz = more or less 1 second.
If I correctly remember, the console buffer cannot exceed 64K, so
the "4 Million chars test" is out anyway.
To have a scrollable 64K buffer, it's enough to fill the 64K buffer,
and allocate the console without fixed dimensions, displaying
on the console the first 4000 chars, authomatic scrollbars will do the rest.
That's more or less the solution I'm thinking about.
A more complex solution, with a buffer up to 2 Gb, a fixed lenght console
screen and console screen buffer of 4000 chars, and WriteConsoleOutput,
or WriteConsoleOutputCharacter to display 4000 chars at a time, using
arrow keys to scroll through the buffer, or PgUp/PgDown to scroll it a page
at a time, and so on.
Both solutions are different from Dave's one, and the latter takes quite a
lot more code and time to work properly. Considering I don't actually need
them, it could only be another [of thousand] deviation from the main goal:
Text File Compressor & Scan.
Well a routine to display the text file to compress or the uncompressed one
could be useful... I'll think about it.
yah - let's say they were different characters, though
let's be realistic :P
I could say some remarks, because this topic seemed free of practical concepts :
1. example PrintTestFormat2 not count presence of LOCALE_SGROUPING, from this follow that this operation much better perfom on string number
2. output 400,000 chars on console better simply preserve by program options, that to get minimal need or output such amount to file straight
3. console output on national code pages sometime require ansi to oem conversion, that slow this even more
So, decision seemed to improve algorithm and not output unneed information on console at all.
Quote from: Adamanteus on January 16, 2013, 10:04:28 PM
I could say some remarks, because this topic seemed free of practical concepts :
1. example PrintTestFormat2 not count presence of LOCALE_SGROUPING, from this follow that this operation much better perfom on string number
2. output 400,000 chars on console better simply preserve by program options, that to get minimal need or output such amount to file straight
3. console output on national code pages sometime require ansi to oem conversion, that slow this even more
So, decision seemed to improve algorithm and not output unneed information on console at all.
1] The LOCALE_SGROUPING is used per default = 3, sorry for countries with
different LOCALE_GROUPING that I'm not interested to manage.
2] It was just a joke between Dave and me. It's difficult to find a real life case
in which you have to display 4 million chars at a time.
3] That is included. Look at the source.
Enjoy
Frank