Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
UDF transmutation
Message
From
15/09/2015 03:00:26
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
14/09/2015 09:14:12
Mike Yearwood
Toronto, Ontario, Canada
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Miscellaneous
Thread ID:
01623094
Message ID:
01624607
Views:
134
>>>I disagree. Once you reach a certain skill level, there is no excuse for not writing the fastest running code possible.
>>
>>There's no excuse for writing slow code.
>>
>>Fastest possible? You'd have to reassess your techniques every time a version of the OS (well, not really OS, but of windowses) changes, to see if all the system level things perform at the same speed or perhaps some of them is now faster or slower than before, or can be replaced with a faster one. Then you'd have to recheck all your code whenever someone posts a speedup here. Eventually you'd get to the point where most of your code is running as fast as possible and fails because of all the things it does not do - things you should have written while you were speeding up the existing code.
>
>>
>>One should code for reliability and correctness first (i.e. the code should do what it should do), then for speed. Speed should also be measured in everyone's time: if my two hours of work will save the users at least ten hours a year, it's worth it. If I'd have to work two days to save them five seconds a year, it's not. I did have to work a couple of decades to be able to make an educated guess between the two, though.
>
>Where did I say I would not code for reliability and correctness? I'm also the biggest proponent of m. which is dismissed by too many.

Where did I say that you did? The difference is in the priorities - I said "reliability and correctness first". Then, time permitting, for speed. "Fastest possible" sounds, to me at least, so absolute and demanding as if it was the prime priority. I'd rather put it on second place - fix if slow, speed it up if you have the time or it annoys you, but in most of the cases you already know what's slow and simply don't do that, and obsessing over speed is not necessary. More speed is probably always possible, but it takes more and more time for smaller and smaller gains, and I guess you see the paradox there.

As long as it's fast enough, there's always other things to do than to revisit the solid working code for speed's sake.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Reply
Map
View

Click here to load this message in the networking platform