Hi,

I read some cases about this problem in the newsgroup before, but didn't 
read a real solution. Nevertheless, as my problem is real, I decided to 
write about that, so I'm sorry if make you bored with the same story:

I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), and 
Windows NT Server SP6 local network at 100 Mbps. The DBF files reside at NT 
Server.

As an example, I take a single report program, that navigates sequentially 
with SKIP all the DBF file and output a formatted list.
The DBF file has 500 records, 77 fields, 1 memo field, and an average 1,200 
bytes record size.

This report with Clipper takes 6 seconds, but with Xbase++ takes 17 seconds 
(almost 3 times more!!!).
I understand that 6 seconds and 17 seconds are both few time, but this 
happens proportionally with large files, so it could be a potential reason 
for users to stop the project.

I've tried copying the Xbase++ EXE and DLLs to the client PC with the same 
results (except Clipper does a little faster). I have not tried to move the 
data files, but think no sense.

I used the same code from Clipper to run to Xbase++ (except some 
adjustments, just to make it run, like the main func definition or Xbase 
includes).

Does anybody have an idea why this happen, and what can I do to make Xbase 
faster?.

Regards,
Alex Ortiz

1 Is the report a separate EXE?? ie do you have to load the exe as a 
separate process to run the report

2 Are you opening the DBFs shared or exclusive???

The main difference is the Clipper goes through the DOS API's where as 
Xbase++ goes through the Windows API's

Jim

Alex Ortiz wrote:
> Hi,
> 
> I read some cases about this problem in the newsgroup before, but didn't 
> read a real solution. Nevertheless, as my problem is real, I decided to 
> write about that, so I'm sorry if make you bored with the same story:
> 
> I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
> The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), and 
> Windows NT Server SP6 local network at 100 Mbps. The DBF files reside at NT 
> Server.
> 
> As an example, I take a single report program, that navigates sequentially 
> with SKIP all the DBF file and output a formatted list.
> The DBF file has 500 records, 77 fields, 1 memo field, and an average 1,200 
> bytes record size.
> 
> This report with Clipper takes 6 seconds, but with Xbase++ takes 17 seconds 
> (almost 3 times more!!!).
> I understand that 6 seconds and 17 seconds are both few time, but this 
> happens proportionally with large files, so it could be a potential reason 
> for users to stop the project.
> 
> I've tried copying the Xbase++ EXE and DLLs to the client PC with the same 
> results (except Clipper does a little faster). I have not tried to move the 
> data files, but think no sense.
> 
> I used the same code from Clipper to run to Xbase++ (except some 
> adjustments, just to make it run, like the main func definition or Xbase 
> includes).
> 
> Does anybody have an idea why this happen, and what can I do to make Xbase 
> faster?.
>

Thanks for your answer James.

1. The report isn't a separate EXE. As the apps are part of the company ERP, 
they are modular, I mean, each app solves a company area (i.e.: ledger, 
accounts payable, etc.), then each EXE contains some PRGs (better said OBJs) 
for reporting, consulting, and on-line transactions.

2. I open the DBFs shared, because they work in a network and as part of an 
integrated system. I can't migrate to ADSDBE because the main reason to 
migrate to Xbase is walking toward Xbase/MySQL, to get integrated to another 
existing apps for Intranet/Extranet/Internet that already are Java/MySQL.

I really appreciate the answer of all participants.

At this point I can conclude there is no way to make Xbase faster, unless 
change the apps to the proper way for Xbase.

Thanks to everybody anyway, and if any of you discover the wheel, let me 
know it.

Best Regards,
Alex Ortiz

"James Loughner" <jwrl@charter.net> escribi en el mensaje 
news:5d5a75ff$5f84c2f9$152923@news.alaska-software.com...
>1 Is the report a separate EXE?? ie do you have to load the exe as a 
>separate process to run the report
>
> 2 Are you opening the DBFs shared or exclusive???
>
> The main difference is the Clipper goes through the DOS API's where as 
> Xbase++ goes through the Windows API's
>
> Jim
>
> Alex Ortiz wrote:
>> Hi,
>>
>> I read some cases about this problem in the newsgroup before, but didn't 
>> read a real solution. Nevertheless, as my problem is real, I decided to 
>> write about that, so I'm sorry if make you bored with the same story:
>>
>> I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
>> The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), 
>> and Windows NT Server SP6 local network at 100 Mbps. The DBF files reside 
>> at NT Server.
>>
>> As an example, I take a single report program, that navigates 
>> sequentially with SKIP all the DBF file and output a formatted list.
>> The DBF file has 500 records, 77 fields, 1 memo field, and an average 
>> 1,200 bytes record size.
>>
>> This report with Clipper takes 6 seconds, but with Xbase++ takes 17 
>> seconds (almost 3 times more!!!).
>> I understand that 6 seconds and 17 seconds are both few time, but this 
>> happens proportionally with large files, so it could be a potential 
>> reason for users to stop the project.
>>
>> I've tried copying the Xbase++ EXE and DLLs to the client PC with the 
>> same results (except Clipper does a little faster). I have not tried to 
>> move the data files, but think no sense.
>>
>> I used the same code from Clipper to run to Xbase++ (except some 
>> adjustments, just to make it run, like the main func definition or Xbase 
>> includes).
>>
>> Does anybody have an idea why this happen, and what can I do to make 
>> Xbase faster?.
>>

Hi James!

[..]
> The main difference is the Clipper goes through the DOS API's where as
> Xbase++ goes through the Windows API's
   Did you ever think about what is so called DOS API in Windows? It just
additional layer, not parallel, over WinAPI. And, of course, plain WinAPI
more faster than DOS API. I'm just check it by following code. The test just
read file with low level file io functions. And, as I'm expected, Xbase++
faster than my clipper 5.2e: Xbase++ 6M/sec and Clipper 4M/sec. I'm use 31Mb
file on network drive.

   So, Xbase++ fast, even faster than clipper (as expected). But why
database operations so slow, times slower than in Clipper? Some times ago
I'm test the same database operations in Clipper and Xbase++ by monitoring
file io by special Filemon tool (www.sysinternals.com) and do not find any
significant difference.. But why Xb++ slower? Don't know...  May be it is
because CORBA layer. I'm never understand what is CORBA for Xbase++
programmers? Why alaskans use it (seems it just a part of VisualAge
compiler)? ???

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

Func FTest(file)
Local h,i,sz
Local buff,sec
Local sc:=Seconds()

 sec:=Seconds()
 h:=FOpen(file,FO_SHARED+FO_READWRITE)

 sz:=FSeek(h,0,FS_END)
 ?sz,h,file

 buff:=Space(10000)

 FSeek(h,0,FS_SET)
 For i:=1 To sz/10000
  FRead(h,@buff,10000)
 Next
 ?Seconds()-sec

Return NIL



--
Eka Muratova,
www.eleussoft.narod.ru

check our software:
>  instiderTools: set of debugging, profiling and error checking tools
>  smartGC: addon tool to speedup garbage collector
>  XFuncs: easy extend your app with script functions

On Tue, 31 Jan 2006 11:51:12 +0700, Eka Muratova wrote:

> Hi James!
> 
> [..]
>> The main difference is the Clipper goes through the DOS API's where as
>> Xbase++ goes through the Windows API's
>    Did you ever think about what is so called DOS API in Windows? It just
> additional layer, not parallel, over WinAPI. And, of course, plain WinAPI
> more faster than DOS API. I'm just check it by following code. The test just
> read file with low level file io functions. And, as I'm expected, Xbase++
> faster than my clipper 5.2e: Xbase++ 6M/sec and Clipper 4M/sec. I'm use 31Mb
> file on network drive.
> 
>    So, Xbase++ fast, even faster than clipper (as expected). But why
> database operations so slow, times slower than in Clipper? Some times ago
> I'm test the same database operations in Clipper and Xbase++ by monitoring
> file io by special Filemon tool (www.sysinternals.com) and do not find any
> significant difference.. But why Xb++ slower? Don't know...  May be it is
> because CORBA layer. I'm never understand what is CORBA for Xbase++
> programmers? Why alaskans use it (seems it just a part of VisualAge
> compiler)? ???
> 

If i remember correctly Steffen in an older post said that they have
allready made some experimental test of Xbase++ without the use of the
som.dll. These experimental tests have as a result huge improvement of the
database access (and not only there) something like 15%-20%. They plan to
include these change in the next major release (2.0)

Regards
Mike Evans

On Tue, 31 Jan 2006 16:16:44 +0200, Mike Evans wrote:

> On Tue, 31 Jan 2006 11:51:12 +0700, Eka Muratova wrote:
> 
>> Hi James!
>> 
>> [..]
>>> The main difference is the Clipper goes through the DOS API's where as
>>> Xbase++ goes through the Windows API's
>>    Did you ever think about what is so called DOS API in Windows? It just
>> additional layer, not parallel, over WinAPI. And, of course, plain WinAPI
>> more faster than DOS API. I'm just check it by following code. The test just
>> read file with low level file io functions. And, as I'm expected, Xbase++
>> faster than my clipper 5.2e: Xbase++ 6M/sec and Clipper 4M/sec. I'm use 31Mb
>> file on network drive.
>> 
>>    So, Xbase++ fast, even faster than clipper (as expected). But why
>> database operations so slow, times slower than in Clipper? Some times ago
>> I'm test the same database operations in Clipper and Xbase++ by monitoring
>> file io by special Filemon tool (www.sysinternals.com) and do not find any
>> significant difference.. But why Xb++ slower? Don't know...  May be it is
>> because CORBA layer. I'm never understand what is CORBA for Xbase++
>> programmers? Why alaskans use it (seems it just a part of VisualAge
>> compiler)? ???
>> 
> 
> If i remember correctly Steffen in an older post said that they have
> allready made some experimental test of Xbase++ without the use of the
> som.dll. These experimental tests have as a result huge improvement of the
> database access (and not only there) something like 15%-20%. They plan to
> include these change in the next major release (2.0)
> 
> Regards
> Mike Evans

I found the document
http://www.alaska-research.com/downloads/docs/linuxdotnet_milestones_EN.pdf

regards
Mike Evans

Locks

Jim

Eka Muratova wrote:
> Hi James!
> 
> [..]
> 
>>The main difference is the Clipper goes through the DOS API's where as
>>Xbase++ goes through the Windows API's
> 
>    Did you ever think about what is so called DOS API in Windows? It just
> additional layer, not parallel, over WinAPI. And, of course, plain WinAPI
> more faster than DOS API. I'm just check it by following code. The test just
> read file with low level file io functions. And, as I'm expected, Xbase++
> faster than my clipper 5.2e: Xbase++ 6M/sec and Clipper 4M/sec. I'm use 31Mb
> file on network drive.
> 
>    So, Xbase++ fast, even faster than clipper (as expected). But why
> database operations so slow, times slower than in Clipper? Some times ago
> I'm test the same database operations in Clipper and Xbase++ by monitoring
> file io by special Filemon tool (www.sysinternals.com) and do not find any
> significant difference.. But why Xb++ slower? Don't know...  May be it is
> because CORBA layer. I'm never understand what is CORBA for Xbase++
> programmers? Why alaskans use it (seems it just a part of VisualAge
> compiler)? ???
> 
> ----------------------------------------------------------------------------
> ----
> 
> Func FTest(file)
> Local h,i,sz
> Local buff,sec
> Local sc:=Seconds()
> 
>  sec:=Seconds()
>  h:=FOpen(file,FO_SHARED+FO_READWRITE)
> 
>  sz:=FSeek(h,0,FS_END)
>  ?sz,h,file
> 
>  buff:=Space(10000)
> 
>  FSeek(h,0,FS_SET)
>  For i:=1 To sz/10000
>   FRead(h,@buff,10000)
>  Next
>  ?Seconds()-sec
> 
> Return NIL
> 
> 
> 
> --
> Eka Muratova,
> www.eleussoft.narod.ru
> 
> check our software:
> 
>> instiderTools: set of debugging, profiling and error checking tools
>> smartGC: addon tool to speedup garbage collector
>> XFuncs: easy extend your app with script functions
> 
> 
>

Hello

It have been explained here several times but my personal opinion is that 
xbase++ is about 3 times slower and more reliable that Clipper.


"Alex Ortiz" <alexortiz@corey.com.mx> escribi en el mensaje 
news:1b76849d$7442c7d7$14c4c0@news.alaska-software.com...
> Hi,
>
> I read some cases about this problem in the newsgroup before, but didn't 
> read a real solution. Nevertheless, as my problem is real, I decided to 
> write about that, so I'm sorry if make you bored with the same story:
>
> I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
> The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), 
> and Windows NT Server SP6 local network at 100 Mbps. The DBF files reside 
> at NT Server.
>
> As an example, I take a single report program, that navigates sequentially 
> with SKIP all the DBF file and output a formatted list.
> The DBF file has 500 records, 77 fields, 1 memo field, and an average 
> 1,200 bytes record size.
>
> This report with Clipper takes 6 seconds, but with Xbase++ takes 17 
> seconds (almost 3 times more!!!).
> I understand that 6 seconds and 17 seconds are both few time, but this 
> happens proportionally with large files, so it could be a potential reason 
> for users to stop the project.
>
> I've tried copying the Xbase++ EXE and DLLs to the client PC with the same 
> results (except Clipper does a little faster). I have not tried to move 
> the data files, but think no sense.
>
> I used the same code from Clipper to run to Xbase++ (except some 
> adjustments, just to make it run, like the main func definition or Xbase 
> includes).
>
> Does anybody have an idea why this happen, and what can I do to make Xbase 
> faster?.
>
> -- 
>
> Regards,
> Alex Ortiz
>

And since my computer is about 3 times faster that it was 5 years,  I can 
continue to develop with old standards at old performance levels. 

Rodd

"Jose Valle" <jm@ejido.net> wrote in message 
news:4d1de7c5$21fa8412$16afd3@news.alaska-software.com...
> Hello
>
> It have been explained here several times but my personal opinion is that 
> xbase++ is about 3 times slower and more reliable that Clipper.
>
>
> "Alex Ortiz" <alexortiz@corey.com.mx> escribi en el mensaje 
> news:1b76849d$7442c7d7$14c4c0@news.alaska-software.com...
>> Hi,
>>
>> I read some cases about this problem in the newsgroup before, but didn't 
>> read a real solution. Nevertheless, as my problem is real, I decided to 
>> write about that, so I'm sorry if make you bored with the same story:
>>
>> I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
>> The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), 
>> and Windows NT Server SP6 local network at 100 Mbps. The DBF files reside 
>> at NT Server.
>>
>> As an example, I take a single report program, that navigates 
>> sequentially with SKIP all the DBF file and output a formatted list.
>> The DBF file has 500 records, 77 fields, 1 memo field, and an average 
>> 1,200 bytes record size.
>>
>> This report with Clipper takes 6 seconds, but with Xbase++ takes 17 
>> seconds (almost 3 times more!!!).
>> I understand that 6 seconds and 17 seconds are both few time, but this 
>> happens proportionally with large files, so it could be a potential 
>> reason for users to stop the project.
>>
>> I've tried copying the Xbase++ EXE and DLLs to the client PC with the 
>> same results (except Clipper does a little faster). I have not tried to 
>> move the data files, but think no sense.
>>
>> I used the same code from Clipper to run to Xbase++ (except some 
>> adjustments, just to make it run, like the main func definition or Xbase 
>> includes).
>>
>> Does anybody have an idea why this happen, and what can I do to make 
>> Xbase faster?.
>>
>> -- 
>>
>> Regards,
>> Alex Ortiz
>>
>
>

I agree with you. Four year ago some clients told me "I found this a little 
slower" but now this is not a problem. We are all happy with Xbase++

Jose Valle


"Rodd Graham" <rodd@tpmco.com> escribi en el mensaje 
news:43e0b2e7$35892d42$16b11b@news.alaska-software.com...
> And since my computer is about 3 times faster that it was 5 years,  I can 
> continue to develop with old standards at old performance levels. 
>
> Rodd
>
> "Jose Valle" <jm@ejido.net> wrote in message 
> news:4d1de7c5$21fa8412$16afd3@news.alaska-software.com...
>> Hello
>>
>> It have been explained here several times but my personal opinion is that 
>> xbase++ is about 3 times slower and more reliable that Clipper.
>>
>>
>> "Alex Ortiz" <alexortiz@corey.com.mx> escribi en el mensaje 
>> news:1b76849d$7442c7d7$14c4c0@news.alaska-software.com...
>>> Hi,
>>>
>>> I read some cases about this problem in the newsgroup before, but didn't 
>>> read a real solution. Nevertheless, as my problem is real, I decided to 
>>> write about that, so I'm sorry if make you bored with the same story:
>>>
>>> I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
>>> The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), 
>>> and Windows NT Server SP6 local network at 100 Mbps. The DBF files 
>>> reside at NT Server.
>>>
>>> As an example, I take a single report program, that navigates 
>>> sequentially with SKIP all the DBF file and output a formatted list.
>>> The DBF file has 500 records, 77 fields, 1 memo field, and an average 
>>> 1,200 bytes record size.
>>>
>>> This report with Clipper takes 6 seconds, but with Xbase++ takes 17 
>>> seconds (almost 3 times more!!!).
>>> I understand that 6 seconds and 17 seconds are both few time, but this 
>>> happens proportionally with large files, so it could be a potential 
>>> reason for users to stop the project.
>>>
>>> I've tried copying the Xbase++ EXE and DLLs to the client PC with the 
>>> same results (except Clipper does a little faster). I have not tried to 
>>> move the data files, but think no sense.
>>>
>>> I used the same code from Clipper to run to Xbase++ (except some 
>>> adjustments, just to make it run, like the main func definition or Xbase 
>>> includes).
>>>
>>> Does anybody have an idea why this happen, and what can I do to make 
>>> Xbase faster?.
>>>
>>> -- 
>>>
>>> Regards,
>>> Alex Ortiz
>>>
>>
>>
>
>

Hi Alex,

Jim gave an very good answer why xBase+ is slower than Clipper.
Namely:
    The main difference is the Clipper goes through the DOS API's where as
    Xbase++ goes through the Windows API's.

But now a solution for your problem:
    Just use Advantage Database Server (ADSDBE) and your problem is totaly 
solved and xBase+ is much faster than ever before.

I tested almost 2 years (it's hardly to believe, but it's realy true) to 
figure out that I needed something like ADS.
Of course you can use something like ODBC, but I don't know if you have to 
change your code than (I don't have experience with that,
only with ADS).

The main reason I tested and tested and tested and tested and tested and 
tested and tested and tested and tested and tested and tested ...
was that the more users there were in a networking environment, the slower 
the aplication. But with ADS it disappeared.

kind regards,


Toni Klammer



"Alex Ortiz" <alexortiz@corey.com.mx> schreef in bericht 
news:1b76849d$7442c7d7$14c4c0@news.alaska-software.com...
> Hi,
>
> I read some cases about this problem in the newsgroup before, but didn't 
> read a real solution. Nevertheless, as my problem is real, I decided to 
> write about that, so I'm sorry if make you bored with the same story:
>
> I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
> The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), 
> and Windows NT Server SP6 local network at 100 Mbps. The DBF files reside 
> at NT Server.
>
> As an example, I take a single report program, that navigates sequentially 
> with SKIP all the DBF file and output a formatted list.
> The DBF file has 500 records, 77 fields, 1 memo field, and an average 
> 1,200 bytes record size.
>
> This report with Clipper takes 6 seconds, but with Xbase++ takes 17 
> seconds (almost 3 times more!!!).
> I understand that 6 seconds and 17 seconds are both few time, but this 
> happens proportionally with large files, so it could be a potential reason 
> for users to stop the project.
>
> I've tried copying the Xbase++ EXE and DLLs to the client PC with the same 
> results (except Clipper does a little faster). I have not tried to move 
> the data files, but think no sense.
>
> I used the same code from Clipper to run to Xbase++ (except some 
> adjustments, just to make it run, like the main func definition or Xbase 
> includes).
>
> Does anybody have an idea why this happen, and what can I do to make Xbase 
> faster?.
>
> -- 
>
> Regards,
> Alex Ortiz
>

On Mon, 30 Jan 2006 13:19:22 -0600, Alex Ortiz wrote:

> Hi,
> 
> I read some cases about this problem in the newsgroup before, but didn't 
> read a real solution. Nevertheless, as my problem is real, I decided to 
> write about that, so I'm sorry if make you bored with the same story:
> 
> I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
> The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), and 
> Windows NT Server SP6 local network at 100 Mbps. The DBF files reside at NT 
> Server.
> 
> As an example, I take a single report program, that navigates sequentially 
> with SKIP all the DBF file and output a formatted list.
> The DBF file has 500 records, 77 fields, 1 memo field, and an average 1,200 
> bytes record size.
> 
> This report with Clipper takes 6 seconds, but with Xbase++ takes 17 seconds 
> (almost 3 times more!!!).
> I understand that 6 seconds and 17 seconds are both few time, but this 
> happens proportionally with large files, so it could be a potential reason 
> for users to stop the project.
> 
> I've tried copying the Xbase++ EXE and DLLs to the client PC with the same 
> results (except Clipper does a little faster). I have not tried to move the 
> data files, but think no sense.
> 
> I used the same code from Clipper to run to Xbase++ (except some 
> adjustments, just to make it run, like the main func definition or Xbase 
> includes).
> 
> Does anybody have an idea why this happen, and what can I do to make Xbase 
> faster?.

The file is opened only from one station or from more. If its open from
more stations be sure that you are using the new feauture of Xbase++ to
speed up a lot these operations. There is a special document about these
settings in the Alaska website.

Regards
Mike Evans

Please tell the link of the document

Thanks++

"Mike Evans" <makis1970@hotmail.com> wrote in message 
news:qr77u8q9idzy.h7waqysyi3i5.dlg@40tude.net...
> On Mon, 30 Jan 2006 13:19:22 -0600, Alex Ortiz wrote:
>
>> Hi,
>>
>> I read some cases about this problem in the newsgroup before, but didn't
>> read a real solution. Nevertheless, as my problem is real, I decided to
>> write about that, so I'm sorry if make you bored with the same story:
>>
>> I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
>> The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), 
>> and
>> Windows NT Server SP6 local network at 100 Mbps. The DBF files reside at 
>> NT
>> Server.
>>
>> As an example, I take a single report program, that navigates 
>> sequentially
>> with SKIP all the DBF file and output a formatted list.
>> The DBF file has 500 records, 77 fields, 1 memo field, and an average 
>> 1,200
>> bytes record size.
>>
>> This report with Clipper takes 6 seconds, but with Xbase++ takes 17 
>> seconds
>> (almost 3 times more!!!).
>> I understand that 6 seconds and 17 seconds are both few time, but this
>> happens proportionally with large files, so it could be a potential 
>> reason
>> for users to stop the project.
>>
>> I've tried copying the Xbase++ EXE and DLLs to the client PC with the 
>> same
>> results (except Clipper does a little faster). I have not tried to move 
>> the
>> data files, but think no sense.
>>
>> I used the same code from Clipper to run to Xbase++ (except some
>> adjustments, just to make it run, like the main func definition or Xbase
>> includes).
>>
>> Does anybody have an idea why this happen, and what can I do to make 
>> Xbase
>> faster?.
>
> The file is opened only from one station or from more. If its open from
> more stations be sure that you are using the new feauture of Xbase++ to
> speed up a lot these operations. There is a special document about these
> settings in the Alaska website.
>
> Regards
> Mike Evans
>

ftp://ftp.alaska-software.com/documents/about_locking.pdf

Pedro Hernández wrote:

>  
> Please tell the link of the document
> 
> Thanks++
> 
> "Mike Evans" <makis1970@hotmail.com> wrote in message 
> news:qr77u8q9idzy.h7waqysyi3i5.dlg@40tude.net...
> 
>>On Mon, 30 Jan 2006 13:19:22 -0600, Alex Ortiz wrote:
>>
>>
>>>Hi,
>>>
>>>I read some cases about this problem in the newsgroup before, but didn't
>>>read a real solution. Nevertheless, as my problem is real, I decided to
>>>write about that, so I'm sorry if make you bored with the same story:
>>>
>>>I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
>>>The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), 
>>>and
>>>Windows NT Server SP6 local network at 100 Mbps. The DBF files reside at 
>>>NT
>>>Server.
>>>
>>>As an example, I take a single report program, that navigates 
>>>sequentially
>>>with SKIP all the DBF file and output a formatted list.
>>>The DBF file has 500 records, 77 fields, 1 memo field, and an average 
>>>1,200
>>>bytes record size.
>>>
>>>This report with Clipper takes 6 seconds, but with Xbase++ takes 17 
>>>seconds
>>>(almost 3 times more!!!).
>>>I understand that 6 seconds and 17 seconds are both few time, but this
>>>happens proportionally with large files, so it could be a potential 
>>>reason
>>>for users to stop the project.
>>>
>>>I've tried copying the Xbase++ EXE and DLLs to the client PC with the 
>>>same
>>>results (except Clipper does a little faster). I have not tried to move 
>>>the
>>>data files, but think no sense.
>>>
>>>I used the same code from Clipper to run to Xbase++ (except some
>>>adjustments, just to make it run, like the main func definition or Xbase
>>>includes).
>>>
>>>Does anybody have an idea why this happen, and what can I do to make 
>>>Xbase
>>>faster?.
>>
>>The file is opened only from one station or from more. If its open from
>>more stations be sure that you are using the new feauture of Xbase++ to
>>speed up a lot these operations. There is a special document about these
>>settings in the Alaska website.
>>
>>Regards
>>Mike Evans
>>
> 
> 
> 
>

Hi everybody,

After many tests, I think to understand why in my case Xbase is slower than 
Clipper.
Let me tell you, so it can be usefull to some others of you.

As you remember, the report I tested read a whole DBF file with skip, then 
build the report.
Building the report is done with @SAY instructions: THIS INSTRUCTION IS THE 
PROBLEM !!!.

Replacing all the "@SAY" with "QOUT" solves the problem.
Don't ask me why, but it's real.

One of my tests was to run the program with no output, just to take time for 
reading all file, then discovered Xbase and Clipper take almost the same 
time (may be Xbase little faster). So adding output I notticed Xbase become 
slower.

I hope this will clarify the question for some people.

Best regards,
Alex Ortiz

"Alex Ortiz" <alexortiz@corey.com.mx> escribi en el mensaje 
news:1b76849d$7442c7d7$14c4c0@news.alaska-software.com...
> Hi,
>
> I read some cases about this problem in the newsgroup before, but didn't 
> read a real solution. Nevertheless, as my problem is real, I decided to 
> write about that, so I'm sorry if make you bored with the same story:
>
> I have some Clipper apps, and trying to migrate to Xbase++ 1.82 Intl.
> The environment is Clipper 5.3, Windows XP SP2 and Pentium 4 (clientes), 
> and Windows NT Server SP6 local network at 100 Mbps. The DBF files reside 
> at NT Server.
>
> As an example, I take a single report program, that navigates sequentially 
> with SKIP all the DBF file and output a formatted list.
> The DBF file has 500 records, 77 fields, 1 memo field, and an average 
> 1,200 bytes record size.
>
> This report with Clipper takes 6 seconds, but with Xbase++ takes 17 
> seconds (almost 3 times more!!!).
> I understand that 6 seconds and 17 seconds are both few time, but this 
> happens proportionally with large files, so it could be a potential reason 
> for users to stop the project.
>
> I've tried copying the Xbase++ EXE and DLLs to the client PC with the same 
> results (except Clipper does a little faster). I have not tried to move 
> the data files, but think no sense.
>
> I used the same code from Clipper to run to Xbase++ (except some 
> adjustments, just to make it run, like the main func definition or Xbase 
> includes).
>
> Does anybody have an idea why this happen, and what can I do to make Xbase 
> faster?.
>
> -- 
>
> Regards,
> Alex Ortiz
>

Alex Ortiz wrote:

> As you remember, the report I tested read a whole DBF file with skip, then 
> build the report.
> Building the report is done with @SAY instructions: THIS INSTRUCTION IS THE 
> PROBLEM !!!.
> 
> Replacing all the "@SAY" with "QOUT" solves the problem.
> Don't ask me why, but it's real.

Well... @ x,y SAY <cText> ist translated by the preprocessor to 
DevPos(x, y) ;DevOut( cText )... so maybe DevPos() or DevOut() is 
slower... although some tests indicate that qout() is significantly slower
than devout()... weird.

Thomas

It depends on what OS you are using. Win9X is slower (in windows mode) 
then NT+ but all have to map the virtual console to a window. It would 
also depends on the hardware ie memory and graphics card etc.

Jim

Thomas Braun wrote:
> Alex Ortiz wrote:
> 
> 
>>As you remember, the report I tested read a whole DBF file with skip, then 
>>build the report.
>>Building the report is done with @SAY instructions: THIS INSTRUCTION IS THE 
>>PROBLEM !!!.
>>
>>Replacing all the "@SAY" with "QOUT" solves the problem.
>>Don't ask me why, but it's real.
> 
> 
> Well... @ x,y SAY <cText> ist translated by the preprocessor to 
> DevPos(x, y) ;DevOut( cText )... so maybe DevPos() or DevOut() is 
> slower... although some tests indicate that qout() is significantly slower
> than devout()... weird.
> 
> Thomas

James Loughner wrote:

> It depends on what OS you are using.

XP prof.

> Win9X is slower (in windows mode) 
> then NT+

Yes - I know this.

> but all have to map the virtual console to a window. It would 
> also depends on the hardware ie memory and graphics card etc.

Regardless of the hardware, IMHO the percentual difference of both methods
should be nearly the same...?

Thomas