>Peter,
>
>When you take into account today's processor speeds, rampamt RAM (pun attempted), fast video drivers, much faster hard drives, etc then the screen bits really has negligible impact. Sure DOS's 2080 characters will be fastest of all, but you should hardly see the difference anymore.
>
>JAVA (or anything else) all operates on the same hardware.

That's the part that makes one want to cry. We are working on computers which are at least 100X more powerful than those of a few years ago not to mention a few decades ago. The first mainframe I worked on (IBM 7040) had about 80KB of memory (16K words), a clock cycle around 1 microsecond, and no disk drive. At a cost of $100,000 the university computer center later doubled (maxed) the memory. A Burroughs B5500 computer of the same era (mid-sixties) could compile Algol programs at 3000 lines per minute.

My HP pentium 166 MHZ can execute over 1 billion cycles in the time in takes to load FoxPro. What is it doing with all those cycles? Why are the programs so huge? There's got to be enormous waste in there.


>There are a few possibilities for factors at work here:
>
>1) VFP development is focussed on mid-tier where visible speed is not a problem.
>The corollary to this is that the VFP team is neglecting the GUI aspects. Since we are constantly told that they are a lean but mean team, this has a real possiblity of being true.
>
>2) Again relating to mid-tier, this time regarding speed generally... VFP obviously is intended to be a front-end to *SOMETHING ELSE*, be it SQL Server or Oracle or whatever, where actual speed is largely determined by the performance of *those* components rather than purely VFP's. So the VFP team might be working real hard to make *THAT* VFP code as tight and fast as possible, but again (small team) at the expense of other things, even including native VFP table access.

It's not just VFP that is slow relative to the capacity of the hardware. Many programs including windows appear to operate more slowly. (Boot time, etc.)


>3) The recent FPA article "Rushmore queries: Less is More" leads to some interesting possibilities too, mainly because this 'problem' has arise quite suddenly. I really have to wonder WHY that is the case. Yes, I know that the article states that the same behaviour was observed in FPD and FPW, but there is still something a little fishy about it. The article did not state whether or not the FPD/FPW runs were performed on a system with VFP also installed on it. I would like to see like tests run on a system known to have had *only* a virgin (from diskette) FPD and FPW installation and with VFP definitely never having seen that particular machine.

Tom Rettig's FP 2.X foundation system would index every field in the database by default. He wasn't known for making dumb choices.


>Where speed was always an issue, maybe it is less so now? - who knows.

I've been thinking about the way that work has changed. When paper forms were filled out and routed to data entry clerks who worked "head down" than pure speed was vital. Many clerks now interface directly with the customer and hardly ever fill out a paper form. Much of the time with the customer is spent in conversation so there is time for the system to process their relatively infrequent key strokes.



>One thing is for sure, and that is that visions of character mode screens really have no real future for the general case.

Agreed. The users (and the suits) are hooked.



>There is, in my opinion, one sure-fire way for MS to have VFP just fade away into the sunset, and that is to stop delivering enhanced GUI functionality *and* neglect speed issues generally. This would juust about guarantee attrition *from* VFP and to any other product which has some nice fancy GUI stuff and adequate speed.
>
>Cheers,
>
>Jim N


It's a situation that bears close scrutiny.

Peter