Speed Report
Joe Wright
from 03:00 to about 10:00 to complete. As I convert these routines to
xHarbour, only the heaviest six so far, the task now ends at 08:30.
Speed improvements over Clipper are uneven but substantial. When we get
to 08:00 Ron gets a Hero award. :-)
I built a .dbf today of over 6 million records of 488 bytes of real
data. Visual FoxPro declares it 'not a table' but xHarbour likes it and
indexes it on one field "val(member_id)" in short minutes. xHarbour
rules! Has anybody pushed xH to its limits? Record length in 16 bits
(65535) and number of records in 32 bits (4294967295). :-)
We can't really make one that big but how big is the biggest?
I will be converting all Clipper to xHarbour at our house.
--
Joe Wright
"Yea though I walk through the valley of the shadow of death, I will
fear no evil, for I am the meanest SOB in the valley." Jerry Sanders
N:dlzc D:aol T:com (dlzc)
"Joe Wright" <joeww...@comcast.net> wrote in message
news:05idnUIjFvxX0hbX...@giganews.com...
> At work I have 50 or more Clipper routines which run
> in a batch and take from 03:00 to about 10:00 to
> complete. As I convert these routines to xHarbour,
> only the heaviest six so far, the task now ends at
> 08:30. Speed improvements over Clipper are
> uneven but substantial. When we get to 08:00 Ron
> gets a Hero award. :-)
>
> I built a .dbf today of over 6 million records of 488
> bytes of real data. Visual FoxPro declares it 'not
> a table'
Probably the header...
> but xHarbour likes it and indexes it on one field
> "val(member_id)" in short minutes. xHarbour rules! Has anybody
> pushed xH to its limits?
Yes, there were reports on the old xharbour news server.
Terabyte file sizes... Przemyslaw Czerpak did some excellent work
on the RDDs too.
> Record length in 16 bits (65535) and number of
> records in 32 bits (4294967295). :-)
>
> We can't really make one that big but how big
> is the biggest?
>
> I will be converting all Clipper to xHarbour at
> our house.
Pretty good stuff...
David A. Smith
Sudip
> I built a .dbf today of over 6 million records of 488
> bytes of real data. Visual FoxPro declares it 'not
> a table'
I am very happy to know this as a Visual FoxPro veteran. :-)
Regards.
Sudip
Patrick Mast
> At work I have 50 or more Clipper routines which run in a batch and
> take from 03:00 to about 10:00 to complete. As I convert these routines
> to xHarbour, only the heaviest six so far, the task now ends at 08:30.
> Speed improvements over Clipper are uneven but substantial. When we get
> to 08:00 Ron gets a Hero award. :-)
>
> I built a .dbf today of over 6 million records of 488 bytes of real
> data. Visual FoxPro declares it 'not a table' but xHarbour likes it and
> indexes it on one field "val(member_id)" in short minutes. xHarbour
> rules! Has anybody pushed xH to its limits? Record length in 16 bits
> (65535) and number of records in 32 bits (4294967295). :-)
>
> We can't really make one that big but how big is the biggest?
>
> I will be converting all Clipper to xHarbour at our house.
Great thing! ;-)
Can I quote this message on our website? Its important we SPREAD THE WORD! ;-))
Thanks Joe.
--
Patrick
Tim Jacob
> At work I have 50 or more Clipper routines which run in a batch and take
> from 03:00 to about 10:00 to complete. As I convert these routines to
> xHarbour, only the heaviest six so far, the task now ends at 08:30.
> Speed improvements over Clipper are uneven but substantial. When we get
> to 08:00 Ron gets a Hero award. :-)
>
> I built a .dbf today of over 6 million records of 488 bytes of real
> data. Visual FoxPro declares it 'not a table' but xHarbour likes it and
> indexes it on one field "val(member_id)" in short minutes. xHarbour
> rules! Has anybody pushed xH to its limits? Record length in 16 bits
> (65535) and number of records in 32 bits (4294967295). :-)
>
> We can't really make one that big but how big is the biggest?
>
> I will be converting all Clipper to xHarbour at our house.
There also appears to be a limitation of 2069 characters in
the length of the dbf header, and a limitation of 189 fields in the
file, whichever comes first, for Clipper 5.2e.
I found this by the process of elimination. 2070 characters is too
much, and 190 fields with less than 2069 characters is still too much.
I don't know what the limitation is in xHarbour, but it's well beyond that
Joe Wright
You can quote me.
Joe Wright
The limitation of number of fields is the distance from the top of the
file to the first record. With only 16 bits we can have 2046 32-byte
field entries plus one 32-byte header.
That's just the arithmetic of it. I don't know what the implementation does.
Robert Campsmith
I have a fairly large commercial app (225,000+ lines of
code) which maintains 58 tables with 94 indexes, all of
which are muliti-key indexes using CDX.
The 'old' Clipper 5.2e app would take between 8 and 9
minutes to completely re-index a database of about 150mg.
My 'new' xHb app (same thing converted) now takes about 2
and a half minutes for a complete re-index.
Screen updates are about 8 times faster. A large report that
took about ten minutes to process about 1,800 records out of
125,000 now takes about a minute and a half!
This speed increase was a very nice byproduct of switching
from C5.2e to xHb. Plus it is a TRUE 32bit Windows app and
with the extend system you can do some pretty nifty things
you could only dream about with Clipper.
Overall, I think it is a great product. We waited a long
time for the wonderful docs that Zeigler wrote. Now I'm just
waiting for complete decent documentation on some of the
specialty stuff like Zip and TIP classes.
Good luck,
-- Robert
Joe Wright
I wanted to see if I could push the xHarbour .dbf to (not beyond) its
theoretical limit. I got this:
4,290,838,562 big.dbf
which is a right hefty file. As described above, its record is 2046
fields of 32 bytes + one byte for the deleted flag, 65,473 bytes. The
structure of the file is 2047 * 32 + 2 or 65506 bytes. Then I append
blank 65535 times, add a single chr(26) at the end et voila!
It took just over four minutes on my old iron.