Clarions slows down on win2000 & XP in

Has anyone discovered system slowing down in WIN2000 or XP while using
simple ADD(something)? We have previously used Windows NT4.0 as OS but now
have to move to 2000 or XP because new hw does not support NT4.0.

Performance in NT4.0 is about 50-100 times faster with the same executable.
Database driver we are using is .tps (topspeed) in Clarion5.5, patch G.

This can easily be verified by making a very simple application just writing
e.g. 500 values to db and measuring the time it takes to complete this.
There is a huge time difference in between running this kind of sample in
NT4.0 and in win2000.

Any help is highly appreciated!

- Seppo Pyorret

Try APPEND(smthng) instead of ADD(smthng)
This might help.

Ivo Ivanov
Modest Automatisering BV
Holland

"Seppo Pyorret" <seppo.pyorret@sr-instruments.com> schreef in bericht
news:c2p9r8$i1t$1@plaza.suomi.net...
> Has anyone discovered system slowing down in WIN2000 or XP while using
> simple ADD(something)? We have previously used Windows NT4.0 as OS but now
> have to move to 2000 or XP because new hw does not support NT4.0.
>
> Performance in NT4.0 is about 50-100 times faster with the same
executable.
> Database driver we are using is .tps (topspeed) in Clarion5.5, patch G.
>
> This can easily be verified by making a very simple application just
writing
> e.g. 500 values to db and measuring the time it takes to complete this.
> There is a huge time difference in between running this kind of sample in
> NT4.0 and in win2000.
>
> Any help is highly appreciated!
>
>  - Seppo Pyorret
>
>

Thanks for the tip but the result is still exactly same. For the speed of
Clarion, I just wonder the speed even on NT4.0: In a simple loop I just
write one value to db (using topspeed as driver) at one time, then repeating
this 500 times -> total time is 7.5 seconds.... In win2000, 65 seconds....
Goes without saying, the performance is very poor.

Regards,

Seppo

Ivo Ivanov <iivanov@modest.nl> wrote in message
news:40503d91$0$154$6c56d894@diablo.nl.easynet.net...
> Try APPEND(smthng) instead of ADD(smthng)
> This might help.
>
> Ivo Ivanov
> Modest Automatisering BV
> Holland
>
> "Seppo Pyorret" <seppo.pyorret@sr-instruments.com> schreef in bericht
> news:c2p9r8$i1t$1@plaza.suomi.net... 
now 
> executable. 
> writing 
in 
>
>

Seppo,

I just figured this was an MS$ inducement to "upgrade" from ISAM to an
SQL engine.  I also assumed that more error/security checking goes on
in 2K© and XP©, but, certainly not 50 to 100 times more!

To get a clear idea of what's going on, just listen to the disk
chatter when writing under 2K and XP, as compared to WIN98/95.  It's
obvious to me theres some code routines in Windoze© that cause the
disk to work so hard.

We're still running TPS and have learned to live with the poor
performance.  Our clients are happy with the performance - mainly due
to our use of only a few routines that write/update thousands records
at one time.  The best I can tell, the speed when writing/updating ONE
record has not been affected - it's just when you need to write/update
hundreds to thousands of records.

Be careful to use Stream/Flush at the proper place in ABC.

WindowManager (ReportManager)
Init PROCEDURE(),BYTE,VIRTUAL
CODE
Source()
Open Files
STREAM(FileName)

Kill PROCEDURE(),BYTE,VIRTUAL
CODE
Short-stop if kill called already
SOURCE
FLUSH(FileName)

Others prefer using Logout() and Commit.  I haven't been able to see
any speed difference ..... but that certainly doesn't mean there isn't
any.

If you discover anything that speeds up disk writes/updates please
post it on the WEB as there are probably thousands of ISAM file users
(not only TPS, but all ISAM users) that would benefit.

Rich Knoch
www.compulink-ltd.com

Hi Rich:

Try Logout(), COMMIT.
You'll be amazed at the speed...

richknoch@cs.com (Rich Knoch) wrote in message news:<1c2ab02e.0403120545.b630aab@posting.go
ogle.com>...
> Seppo,
>
> I just figured this was an MS$ inducement to "upgrade" from ISAM to an
> SQL engine.  I also assumed that more error/security checking goes on
> in 2K© and XP©, but, certainly not 50 to 100 times more!
>
> To get a clear idea of what's going on, just listen to the disk
> chatter when writing under 2K and XP, as compared to WIN98/95.  It's
> obvious to me theres some code routines in Windoze© that cause the
> disk to work so hard.
>
> We're still running TPS and have learned to live with the poor
> performance.  Our clients are happy with the performance - mainly due
> to our use of only a few routines that write/update thousands records
> at one time.  The best I can tell, the speed when writing/updating ONE
> record has not been affected - it's just when you need to write/update
> hundreds to thousands of records.
>
> Be careful to use Stream/Flush at the proper place in ABC.
>
> WindowManager (ReportManager)
>    Init PROCEDURE(),BYTE,VIRTUAL
>       CODE
>         Source()
>           Open Files
>           STREAM(FileName)
>
>    Kill PROCEDURE(),BYTE,VIRTUAL
>       CODE
>         Short-stop if kill called already
>         SOURCE
>            FLUSH(FileName)
>
> Others prefer using Logout() and Commit.  I haven't been able to see
> any speed difference ..... but that certainly doesn't mean there isn't
> any.
>
> If you discover anything that speeds up disk writes/updates please
> post it on the WEB as there are probably thousands of ISAM file users
> (not only TPS, but all ISAM users) that would benefit.
>
> Rich Knoch
> www.compulink-ltd.com

Gentlemen, thank you very much for your comments, especially Rich !

Yes, Rich you are correct in stating that the performance is not 50 - 100
times slower in win2000 than in winNT4.0. According to simple test I made,
the difference is in 12 -15 times slower in win2000 than in NT4.0. As in
time units, we are talking 17 ms (millisecond) writing time in NT, and
approximately 0.2 seconds in win2000 (one ADD(value)!). Using either
logout/commit or stream/flush  speeds up the performance in batch
processing.

Also, the single writing to db is as slow as it was in the tests made. Since
we are having two executables (the application itself), 1) database part and
2) userface part, this slow writing to db causes heavy headache. Thanks to
your simple example, now I have an idea how to overcome this problem but the
repair is far away from being simple and pretty: In the user interface I am
planning to pass request for db access periodically via pipes. After
request, streaming is turned off for userface to update the files in db. Not
too nice way to handle this but I really can't imagine other way.

I wonder if all users of Clarion are aware of this restriction because this
affects directly to design of software. For example, using disk accesses
only in background while memory structures are used in normal processes.

This slow behaviour is really a big clue. If something new comes up, I will
certainly share it with others.

Regards,

Seppo


Ken Stone <stone@dhhs.state.sc.us> wrote in message
news:9899aafb.0403150621.29e29b7a@posting.google.com...
> Hi Rich:
>
> Try Logout(), COMMIT.
> You'll be amazed at the speed...
>
> richknoch@cs.com (Rich Knoch) wrote in message
news:<1c2ab02e.0403120545.b630aab@posting.google.com>...