FYI: Execution Speed - Clipper

Dear Bill Ding:

"Bill Ding" <carpenter@construction.net> wrote in message
news:eoduc801mo5@news2.newsguy.com...
> FYI - Execution Speed
>
> How long does it take to execute a program?

....
> The program's basic function is to examine a month's worth of
> data from a
> POS system's sales log (.dbf), and copy only selected items
> into a
> separate .dbf file. It begins by copying the sales log to a
> temporary file
> for processing, then creates an empty file to contain the
> selected items,
> then indexes the inventory file, sets a relation from the
> (temporary)
> sales log into the inventory file via the newly created index,
> and steps
> through the sales log and copies the records for which a flag
> is set in
> inventory, listing the records copied.
....
> Compiler Time, seconds
> ---------- -------------
> Clipper 92
> xHarbour 61
> FoxPro 15 (direct)
> FoxPro 7 (compact .exe)
> FoxPro 15 (standalone .exe)
>
> For a few tens of seconds saving, I sure as hell wouldn't
> change
> anything... but if things scale directly, and it turned into
> running the
> process in ten minutes versus two hours, I'm pretty effing sure
> what
> compiler I'd be using.
>
> Maybe the subjext line should be "Ten Year-old FoxPro Kicks Ass
> on
> Clipper, xHarbour"
>
> Your mileage may vary.

What RDD did you include in Clipper and xHarbour?

10 years old... was that before Microshaft took it over?

David A. Smith

Bill,

That sounds pretty fair, next time add a test of dBaseIII!

Fox always was fast. If a Clipper program is not quick enough, you can
rewrite that code in C or asm. That was a feature the foxpro guys have
always envied.

Mike

On Sun, 14 Jan 2007 13:03:11 -0700, N:dlzc D:aol T:com (dlzc) wrote:

>
> What RDD did you include in Clipper and xHarbour?
>
Default - I didn't look, but AFAIK it would be ntx.

> 10 years old... was that before Microshaft took it over?

Indeed, and I think JUST before M$ grabbed it (apparently to stifle
competition for M$ Excess). While I have dabbled with Vis Fox 3,5, and 6,
I have not had my hands on M$ DOS Fox (if there WAS one - I think there
was, but not certain).

--

He who never sticks out neck, never wins by nose.
-- Jimmy Chan (#1 Son)

On Sun, 14 Jan 2007 12:29:42 -0800, Mike wrote:

> Bill,
>
> That sounds pretty fair, next time add a test of dBaseIII!

I'd have to dig pretty far into 5 1/4" floppies to find it... I'd guess
dbIV would show up quicker... but I won't, 'cause I don't use it, but I DO
still use FoxPro for quick little ad hoc stuff.

You know, I'd probably use pp (or xbscript or whatever its name is this
week) if it weren't for the fact that, as one of my ol' coaches used to
say, it cain't carry Fox's jockey strap. Oh, I do use it, on linux boxes
where there ain't no Fox, but I don't much care for it. Hell, it can't
even carry MFox's jock, come to think of it.

> Fox always was fast. If a Clipper program is not quick enough, you can
> rewrite that code in C or asm. That was a feature the foxpro guys have
> always envied.

Back when networking meant arcnet and terminals were cheaper by far than
386 PC's, we did a few versions using CodeBase on SCO systems. Worked
pretty damn good, too... I think we even got so far as to using - or
trying to use - an almost-working SCO Fox, but the bottom fell out of the
market, and it got to be cheaper to install LANs than termnets...


--

Pure drivel tends to drive ordinary drivel off the TV
screen.
-- Ronald Reagan (who should know full well)

Bill Ding wrote:
> On Sun, 14 Jan 2007 13:03:11 -0700, N:dlzc D:aol T:com (dlzc) wrote:
>
>> What RDD did you include in Clipper and xHarbour?
>>
> Default - I didn't look, but AFAIK it would be ntx.
>
>> 10 years old... was that before Microshaft took it over?
>
> Indeed, and I think JUST before M$ grabbed it (apparently to stifle
> competition for M$ Excess). While I have dabbled with Vis Fox 3,5, and 6,
> I have not had my hands on M$ DOS Fox (if there WAS one - I think there
> was, but not certain).
>
There was indeed. FoxPro 2.6 and very popular up to about ten years ago.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Bill,

> You know, I'd probably use pp (or xbscript or whatever its name is this
> week) if it weren't for the fact that, as one of my ol' coaches used to
> say, it cain't carry Fox's jockey strap. Oh, I do use it, on linux boxes
> where there ain't no Fox, but I don't much care for it. Hell, it can't
> even carry MFox's jock, come to think of it.

Could you please explain the above comment? I'd greatly appreciate
detailed info.

Ron

On Sun, 14 Jan 2007 12:57:55 -0600, Bill Ding wrote:

> FYI - Execution Speed
>
> How long does it take to execute a program?
>
> There are many timing programs designed to test how long programs will
> run, going through all sorts of functions... reading, writing, indexing,
> screen output, printer output, on and on and on... and while they're all
> well and good, let's face facts: nothing takes the place of YOUR program,
> does it?
>
> A couple of days ago, more or less by accident, I happened to fall into an
> execution-speed test, and I thought you might like to see the results.
> While I'm sure that some people are going to want to see the actual code
> so they can explain the differences, I'm just going to describe the
> program, called xtract, and let it go at that.
>
> The program's basic function is to examine a month's worth of data from a
> POS system's sales log (.dbf), and copy only selected items into a
> separate .dbf file. It begins by copying the sales log to a temporary file
> for processing, then creates an empty file to contain the selected items,
> then indexes the inventory file, sets a relation from the (temporary)
> sales log into the inventory file via the newly created index, and steps
> through the sales log and copies the records for which a flag is set in
> inventory, listing the records copied.
>
> That's it. Simple, straightforward... yes, it's not the best way to do it,
> but it was created in a mode I am sure you are all more than familiar
> with: quick and cheap.
>
> The end user's copy of this program is in Clipper 5.2e and executes on a 2
> GHz machine running WinXP. In this case, the sales log consisted of about
> 75000 records and the inventory of about 4500 records. The joining field
> is 15 bytes in each file.
>
> In testing another computer which had just had xHarbour (0.99.6)
> installed, I grabbed that program to see if it would be easily converted,
> principally because it was right there in front of me. It actually took a
> single change (adding proc main at the top) and ran immediately. Having
> not seen the program run with "real" data, I thought it was a little slow
> - it took 61 seconds to execute.
>
> Hmmmm... I went back to the Clipper compiler and built the "new" program
> with Clipper. It took 92 seconds.
>
> Somewhat non-plussed, I tried FoxPro (this was a 2.6 for DOS version - I
> didn't bother with any "visual" versions) - changing two lines (FoxPro
> doesn't like statements like COPYIT(cItem) - it wants either
> something=COPYIT(cItem) or DO COPYIT WITH cItem... and Clipper and
> xHarbour are happy with any of the three - when I'm doing code that may go
> either way I usually use a "junk" variable and code it like
> junk=copyit(cItem)... for what that's worth to you).
>
> Long story short, FoxPro was unbelievable faster, in three different
> versions. First I just ran it directly, in the command box by keying in DO
> xtract. To my amazement, it took just over 15 seconds. I built a "compact"
> exe, which is one that requires the foxpro executable library in the path
> - in this case it was to be found in c:\fox26dos - creasting an xtract.exe
> about 16K in size, then exited to a DOS prompt and ran it - in just over 7
> seconds! I went back into Fox, creating a standalone xtract.exe, which was
> arounf 960K in size, and ran it from the DOS prompt, taking about 15
> seconds.
>
> So, for whatever reasons, which I would be happy to see discussed, here
> are the results summarized:
>
> Compiler Time, seconds
> ---------- -------------
> Clipper 92
> xHarbour 61
> FoxPro 15 (direct)
> FoxPro 7 (compact .exe)
> FoxPro 15 (standalone .exe)
>
> For a few tens of seconds saving, I sure as hell wouldn't change
> anything... but if things scale directly, and it turned into running the
> process in ten minutes versus two hours, I'm pretty effing sure what
> compiler I'd be using.
>
> Maybe the subjext line should be "Ten Year-old FoxPro Kicks Ass on
> Clipper, xHarbour"
>
> Your mileage may vary.

Bill,
The best you can do is to post the source for the sample and also the data
(with a link) so it will be possible to check whats happen under the hood.

Regards
Mike Evans

On Mon, 15 Jan 2007 03:49:40 -0800, Ron Pinkas wrote:

> Bill,
>
>> You know, I'd probably use pp (or xbscript or whatever its name is this
>> week) if it weren't for the fact that, as one of my ol' coaches used to
>> say, it cain't carry Fox's jockey strap. Oh, I do use it, on linux boxes
>> where there ain't no Fox, but I don't much care for it. Hell, it can't
>> even carry MFox's jock, come to think of it.
>
> Could you please explain the above comment? I'd greatly appreciate
> detailed info.
>
> Ron

FoxPro - and MFox, for that matter - are far superior to pp (or
xbscript) as a "command line" type database tool. You presumably have
used both; if you don't agree, please explain how pp is better.

--

Success is simply a matter of luck. Ask any failure.
-- Earl Wilson

On Mon, 15 Jan 2007 13:51:27 +0200, Mike Evans wrote:


> Bill,
> The best you can do is to post the source for the sample and also the data
> (with a link) so it will be possible to check whats happen under the hood.

I could post the code, but it's pointless without the data, and the data
is real and proprietary to a client.

--

I detest life insurance agents. They always argue that
I shall some day die, which is not so.
-- Stephen Leacock