Is DDT slow?

[Lance Edmonds]

Originally posted by Borje Hagsten:
A small question on "ON ERROR RESUME NEXT": I have been under the impression that
using "IF ERR THEN.." after critical parts in code is a bit faster/leaner and even
a bit "safer". Is it just something I have dreamt? I sometimes tend to mix things up.

As compared to ON ERROR GOTO?

Using ON ERROR RESUME NEXT (the default) is perfectly "safe" as long as you carefully write your code to trap all possible errors (or at least the crippling ones!), whereas using ON ERROR GOTO is "guaranteed" to trigger on all runtime errors (except GPF's, etc!).

Really it comes down to coding style (personal preference) and the task at hand, for the choice of which error detection scheme you employ in each sub/function in your code.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Fred Oxenby]

I feel so dumb.
I feel so stupid.
I am the most ignorant programmer in the world.
And I am stupid too.
I am sorry to have occupied your good time with a question like this.
-----
Some of you, perhaps recall a thread about a rotten novell-network,
some month ago.
My customer forced me to implement excessiv retries on file-operations
Like this:

   FilNr& = GetFreeFile()
   Retry& = 0
   Do 
    ErrClear:Open TransIdxDir$ & FilNamn$ For Binary Access Read Lock Shared As FilNr&
    If ErrClear = 0 Then Function = %True:Exit Do
    If Retry& > 5   Then Function = %False:GoTo ErrExit
    Incr Retry&:Sleep 50
   Loop

And I used an old app (without retries) to compare with (have I said I am stupid)
In my development-environment I do not have production-database so
all seeks there took 2*250 ms for every entry as all lookups failed.
After simply removing the database-lookup reading all loggfile/updating
the listbox took only 16 seconds, and DDT-engine had no problem to keep
up with incomming messages.

2 days of completly wasted time, mine and yours.
sorry


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Chris Boss]

Lance;

Fred is not talking about EZGUI (the GUI engine), but he is using
my freeware DDT Visual Designer (which is pure DDT and no runtime)
so his problem is with DDT and not EZGUI (since he isn't using EZGUI).

EZGUI 1.0 uses Form name strings, while the code generated with my
DDT Visual Designer uses standard handles required by DDT.

Fred;

I believe you own a copy of EZGUI 1.0 !

Have you tried using it, just for a test, to see if it is slow too ?

I would suggest trying to use EZGUI 1.0 (just as a test) to see if
the dialogs are slowing things down. EZGUI should have slightly more
overhead that DDT would, so I would expect it to be very slow if
you think DDT is very slow. EZGUI 1.0 uses the Windows Dialog engine
(note 2.0 doesn't use the Windows Dialog engine anymore), so it
should be comparable to DDT.

EZGUI 1.0 has a reasonbly optimized message loop (as long as you don't use
Modal windows), so it would make a good test.

If EZGUI 1.0 is slow too, then the problem likely lies with the
Windows Dialog engine and you will have to do a little searching to
find the bottleneck.

Note: When you use any type of code that depends upon the
Windows Dialog engine, Modal Dialogs will not use the message
loop provided (by DDT or EZGUI 1.0). Modal Dialogs use a message loop
provided by Windows itself and not the message loop in the app itself.



------------------

[Chris Boss]

Fred;

I had a strong feeling it was something else that was being
overlooked !

For those of you who are "lurking":

While it is true the Windows Dialog engine (which affects DDT and
EZGUI 1.0) does have more overhead than using CreateWindow (SDK), the
difference in speed between the two should be negligable !

Whether you use SDK, DDT, EZGUI or the Windows Dialog Engine directly,
the major slow down in Dialog display will be the graphic nature of
Windows and higher resolutions used by Video adapters today,

Most Dialog engines (ie. DDT, EZGUI) use very little code to do what
they do and most of that code is just a few Integer calculations. We are
talking about milliseconds here. The Video adapter on the other hand
must have thousands to millions of bytes moved around for every single
tiny modification of the screen. Compared to DOS, Windows major slow down
is the Video adapter and all the work it has to do. With the high speeds
of CPUs today the calculations made by Dialogs is insignificant. It is
the video adapter manipulation that is the hog.

ie.

In a DOS text screen, you could change an entire text screen by poking 2000 bytes
(2 KB) to the video adapter. To change a single line of text would only require
160 bytes.

Now, in a Windows app, most computers are running high resolutions.

For example an 800 x 600 resolution using 24 bit color requires
1,440,000 bytes (1.4 Meg) to be moved for a single screen update.

A single line of text (comparable to a single line in DOS) would be
57,600 bytes (57 KB). Now with Windows, screen pixels are not just
simply poked into Video Ram. Windows uses complex Device contexts
to control writing to Video ram. It uses clipping and other stuff that
produces a huge overhead in simply writing data to the Video adapter.

This means that conceivably Windows can take as much a 1000 to 5000 times
(any maybe more) longer to update screen data as DOS. If Windows could simply poke
data into video ram, it would take 720 times as long as DOS to update
a single screen.

Simply put, if you are having problems with speed of updating a Dialog
the overhead of DDT or the Windows Dialog engine (or even EZGUI) is
simply negligable compared to suchs things as writing data to the
Video adapter which all apps have to do (through Windows of course).

Fred's case was obviously one dealing with disk access (which is slow
too).

The moral of the story :

If your Dialogs seems sluggish in updating data, then first look at
how much data you are actually trying to push onto the screen and how
fast and remember the graphic nature of Windows slows things down
terribly.

Second, look for errors in your algorythms or disk access code and
look for bottlenecks there.

Fred;

I am glad you finally found your problem !

And No you aren't stupid !

I don't know how many times I have felt like a dog chasing his tail
trying to fix a bug, only to find it was some very simple error.

A good programmer is not one who never make a mistake. He is one who
has made plenty of mistakes , but has learned a number of lessons
from those mistakes.




------------------

[Lance Edmonds]

Originally posted by Chris Boss:
Lance;
Fred is not talking about EZGUI (the GUI engine), but he is using
my freeware DDT Visual Designer (which is pure DDT and no runtime)
so his problem is with DDT and not EZGUI (since he isn't using EZGUI).

Ok, we'll accept your retraction... the problem is NOT DDT!




------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Paul Dwyer]

Fred,

Question slightly off topic, I notice you code contains chars outside the ASCII set (ie, in the 128 and above ANSII set)
have you noticed any problems with DDT using these sorts of strings?

Forget the unicode issues obviously, I have had a lot of problems using the over 127 char set because of font issues and I'm wondering if you've had them too...

eg, I pass a label set to system font text like "“ú–{Œê‚̃eƒLƒXƒg"@and it's fine but in the dialog caption it's garbage, even if wrtten, compiled and run on the desired OS...

Comments are very welcome because I've overcome these issue with unicode but not on the native 98 and ME systems... (Hate thoses OS's)



------------------
Paul Dwyer
Network Engineer
Aussie in Tokyo

[Bern Ertl]

This thread is splitting into different directions, but I wanted
to clarify something Borje touched on earlier regarding error
handling.

If one uses ON ERROR GOTO/GOSUB the compiler necessarily adds
error checking code after every PB statement, doesn't it? Whereas
using IF ERR THEN whenever one suspects error possibilities does not
force the compiler to add such error checking throughout the code
(section).

Therefore, Borje's original assertion about LEANER code using
IF ERR vs. ON ERR is correct, isn't it? I wouldn't begin to imagine
that it is "SAFER" - too many variables to make such a claim...

------------------
Bernard Ertl

[This message has been edited by Bern Ertl (edited March 19, 2001).]

[Borje Hagsten]

Hm, yes, but then again, since PB already produces such lean code, that
is not a big deal. What I meant by "safer" is that many programmers tend
to use ON ERROR RESUME NEXT, without doing anything more.

This can lead to disaster, if the error for example has caused a stop
variable to remain blank before entering a loop, etc. Like Lance says,
it's a personal taste. I just happen to like IF ERR THEN after critical
points better..


------------------


[This message has been edited by Borje Hagsten (edited March 19, 2001).]

[Fred Oxenby]

Originally posted by Paul Dwyer:
Fred,
Question slightly off topic, I notice you code contains chars outside the ASCII set (ie, in the 128 and above ANSII set)
have you noticed any problems with DDT using these sorts of strings?

"MS Sans Serif" and "Helv" cannot correctly display double-byte strings. Therefore, under a DBCS-enabled system,
dialog boxes need to use the system font instead.
I dont know if you have tried this...
Otherwise, as this thread is a living proof, I do not use DDT much
The swedish "national characters" have been arond since 1980 in a standard way (Dos PCU10)
and I have learned to only use proven fonts. In the Anglo-word people still
live in the 7-byte ascii-world (I suppose they still use tele-type), rest of the word turned to
the 8-bit ascii in the 1980-s
The only advice I can give is to check what "picture" is assingned to characters
obove 127

------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se

[Fred Oxenby]

Originally posted by Borje Hagsten:
A small question on "ON ERROR RESUME NEXT": I have been under the impression that
using "IF ERR THEN.." after critical parts in code is a bit faster/leaner and even
a bit "safer". Is it just something I have dreamt? I sometimes tend to mix things up..

Old habbits die hard
I tend to start all SUB/FUNCTIONS with disabling error-trapping = ON ERROR RESUME NEXT.
(This is only to visualize to me and other reading the code that there are only error-handling
where explit done so with IF ERR(CLEAR) THEN ..)
Then I use ErrClear to clear the ERR-variable before I code an instruction that will be
checked for error. Theoretical this could mean that my code is prune to GPF-s.
Errors when opening a file has one type of recovery, when writing or reading another, so I
find it more efficient to handle errors where it occure (in code), even if this mean that
I repeat the same code over and over again.
I have considered this approach:

Function SomeFunction()as long
  On Error GoTo Errhandler
  .....
  Errclear:Open File$ for binary as #1
  If ErrClear > 0 Then 
  ...
  ...
Errhandler:
  Resume next
End Function

But that does not work in PB as RESUME need a label. And RESUME resets the ERR-variable (I think)


------------------
Fred
mailto:[email protected][email protected]</A>
http://www.oxenby.se



[This message has been edited by Fred Oxenby (edited March 19, 2001).]

[John Kovacich]

Fred, to disable error checking don't you need to use
On error goto 0?

Lance, I'm not sure I would call on error resume next safer, since
any called subroutine or function would carry over this and may not
tip you off when you have an error. However, I do use it personally,
but I set on error goto 0 for critical sections, especially while I'm
debugging.

------------------
Thanks,

John Kovacich

[Lance Edmonds]

John, maybe you have misread or misinterpreted my message...?

To be clear, ON ERROR RESUME NEXT and ON ERROR GOTO 0 both produce the same results... they disable the error handler (if one exists).

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>