On Tue, 2 Oct 2007 10:27:19 -0300, Claudio Voskian wrote:

> Mike
>
> "Mike Evans" <makis1970@hotmail.com> escribió en el mensaje
> news:4701f383$0$1346$834e42db@reader.greatnowhere. com...
>> On Fri, 28 Sep 2007 12:43:03 -0300, Claudio Voskian wrote:
>>
>>> Mike
>>>
>>> "Mike Evans" <makis1970@hotmail.com> escribió en el mensaje
>>> news:1q8f6citbglnt$.sc3wi32oydfk.dlg@40tude.net...
>>>> On Fri, 28 Sep 2007 10:42:25 -0300, Claudio Voskian wrote:
>>>>
>>>>> Hi Ted and others
>>>>>
>>>>> "Ted" <ted.kobayashi@gmail.com> escribió en el mensaje
>>>>> news:1190948453.740083.48980@k79g2000hse.googlegro ups.com...
>>>>>> Well, excuse me. I had previously done a timing test between Clipper
>>>>>> and xHarbour about a month ago and the result was xHarbour was about
>>>>>> 20% slower (or so I thought). I tried to locate the tests, but it is
>>>>>> either in the bit bucket or alzheimer's creeping in. So, I tried the
>>>>>> timing test on a current project: 1 million records, each seeking into
>>>>>> another dbf, then looping through a small 300 record dbf, then
>>>>>> outputting 1+ million records with additional fields. Here are the
>>>>>> unscientific results. Clipper using DBFCDX 41.67 minutes. xHarbour
>>>>>> using DBFCDX 33.48 minutes, xHarbour DBFNTX 31.21 minutes. In this
>>>>>> test, xHarbour was significantly FASTER. Seems suspicious the NTX was
>>>>>> a little faster than CDX, but I'm not going to argue. I guess I
>>>>>> should have rebooted before each run. I may do the test again when I
>>>>>> have more time. Any comments on the times above? Are they consistent
>>>>>> or inconsistent with anyone else's tests? By the way, the tests were
>>>>>> on W2000, AMD 2.2GHz, SCSI 160 drive, Clipper 5.3b, and the latest
>>>>>> xHarbour. Might be interesting to run these tests on my XP computer.
>>>>>> I'll work on that.
>>>>>>
>>>>>> Thanks for reading,
>>>>>>
>>>>>> Ted
>>>>>>
>>>>>
>>>>> I'm using the pro version and found that it is very slow when used in a
>>>>> network environment.
>>>>> Every networks is different, I know, and I don't know if the one I use
>>>>> is
>>>>> properly adjusted (it is my client's network, where the real things are
>>>>> going, which, by the way, is a novell netware 5.1 in a P4 server,
>>>>> tcp/ip
>>>>> +
>>>>> ipx, 10/100 switched network, workstations are w2k pro).
>>>>>
>>>>> In fact, anything I tried to do was much slower compared with the
>>>>> equivalent
>>>>> clipper application +comix or +six3 still in use (up to now, they were
>>>>> just
>>>>> recompiled and do minimal changes to make it work).
>>>>>
>>>>> Don't know how to get a quantum in speed ... it was one of the reasons
>>>>> to
>>>>> go
>>>>> to xharbour (between others, of course).
>>>>>
>>>>> Examples:
>>>>> build .cdx indexes from scratch (in big databases of >500.000 records),
>>>>> slower than cl5.2e
>>>>> 'select' a set of records using bit mapped filters (like the ones in
>>>>> comix
>>>>> or six3), painly slow
>>>>> browse a table with or without filter installed, a bit slow than in
>>>>> clipper
>>>>>
>>>>> BUT: If it runs locally (copying all the files to C:\, so no network is
>>>>> involved), it works really fast and works great (it is a cache related
>>>>> thing).
>>>>>
>>>>> My next try will be a migration to mysql, but it is in my mind only.
>>>>>
>>>>> Have a nice day,
>>>>
>>>> Claudio,
>>>> One user access the file from the network drive or many concurrent?
>>>> Also which xHarbour RDD you are using and with what DBFLOCKSCHEME value?
>>>> Regards
>>>> Mike Evans
>>>
>>> The usual thing in a network environment is that there are many users
>>> accessing files concurrently.
>>> Except when indexing (i.e., "exclusive use" by the nature of the
>>> process),
>>> the remaining tests were done with shared access.
>>>
>>> The dbflockscheme I use is 3 (don't know what could it affect), and the
>>> rdd
>>> is rmdbfcdx (in the app. that uses six3, also uses sde61.lib); take into
>>> account that for this tests the files are not being shared between the
>>> clipper version and the xharbour one. They are installed on different
>>> folders on the same file server, but not shared at all between them (this
>>> is
>>> just to avoid further problems).
>>>
>>> The test was done in a normal labor day (yesterday), with all people
>>> working
>>> so the server and the network were busy (as usual). Obviously my customer
>>> is
>>> a little worried.
>>>
>>> Regards,
>>
>> Claudio,
>> Try DBFLOCKSCHEME 2. (Its like clipper 5.3 default sharing locking scheme.
>> Also As i said until the latest version (i didn't try it until now)
>> filters
>> need the second part for logical expressions ( fielda == .t. ) to be
>> optimized. Clipper does need this. Also DEPENTED FROM THE FILE SIZE and
>> because clipper using cache in dbf files is faster tha xHarbour (this one
>> is aknoeledge by przemek). In general as Przemek said when the file
>> getting
>> bigger (and the clipper caching mechanism is not possible to cache)
>> xHarbour again getting faster). Also especially for the Browse look
>> carefully for calls to ordkeycoynt ordkeyno. This 2 fuctions are a lot
>> slower in xHarbour RMDBFCDX because xHarbour does not use cache for this
>> operations. I hope that someday Przemek will add Caching to RMDBFCDX and
>> i'm sure that will see xHarbour shine under all circumstances. Also have
>> in
>> mind the sreen display under xHarbour is a lot slower than clipper and
>> from
>> GT to Gt is even worst. Fo such operations that display continiously in
>> the
>> screen add special algorithm no to display allways in the screen.
>
> ---
>
> Thank you for responding me.
> Will try dbflockscheme=2, but I think its functionality is related with the
> way (or the offset at which) the locks are set in a database; it is a
> compatibility function when sharing the same set of databases using
> different applications (one written in clipper, another with xh). Don't
> think it could affect performance, but I'm not an expert in that.
>
> Also I will look at the expressions used in the calls to the filtering
> functions (with rmdbfcdx), some of they are 'pre-programmed' in the source
> files, but the user can add its own expressions (I left them instructions in
> how-to-do that).
> Anyway, I should have to experiment a lot with this new toy before going to
> some flavour of sql in the near future.
>
> For the screen refresh been slow, it is not as important anyway. Is there
> any replacements for the functions you mentioned (ordkeycount / ordkeyno)?
>
> An out of topic:
> Too much people were talking about Przemyslaw Czerpak as a genius; I
> understand that he has been one of the main developers of the rdd layers...
> so, he should be a genius; my questions are:
> - What is he doing now?
> - Does he 'work' with/at the xharbour team?
> - Can be contacted in some way?
> I see in the news that he actively responded to any question in the past,
> but I don't see any post from him from long time ago.
>
> Have a nice day, it's rainy here.
> Claudio