>One thing many developers don't do (yet) or perhaps don't consider is to put code in place to track which pieces of their app is slugging along compared to others.

Here I agree to about 300% (stealing some agreement from coworkers...)

>There are some nice profiling tools out there now for those who don't want to code it on their own.

And here I tend to disagree - at least as starting option.
IMHO every project should have logging capability,
and this log should have the capability to log runtime as well.
When you are profiling, most of the time the runtime characteristics will be influenced
by the profiler (Heisenberg comes to mind...) - best example is the slow SQL taking 5 sec in five runs compared to the5 runs of a subroutine which calls calls 32000 fast other lines taking 20s when profiling but only .5 sec when running without profiling tool.

>
>Bad code is bad code. Inefficient code can sometimes be just as bad. Just as in VFP, there are 100 ways to skin a cat in .net. 99 of those ways may be slower than 1 of them. If you can identify the forms that load slow or close slow or other pieces of your app that are slow then you can look for more efficient coding options... (sometimes it really is the design pattern causing the issue and other times it has nothing to do with it and developers use the design pattern as an excuse for the delays in some areas of their app)

And you get more than a subconcious feel for the app - the minute some bad code is introduced,
you can identify it without much problem, as you still have a "fast option" in SSafe.

>
>One benefit .net has over VFP is multi-threading. (I'm not trying to start the discussion on multi-threading in VFP - I have some apps doing that). There are times it can be used to greatly improve the speed of an app and other times when it can be deadly. Sometimes multi-tasking is a better option. Writing benchmarks can be helpful....

As you remember I have done quite a few chores that way myself...
From an isolation POV using tasks can be much easier - but under which comparable scenario was it faster to use tasks ? One possibility I can imagine is having to check/switch a lot of global vars/settings, but that has a smell of its own ? YOu always get hit by marshalling across process boundries, even in non-chatty code.

Slightly OT:
Just as recommended reading I urge you to try Node.Js -
it gives you a leg up in Javascript as a language
(not that I reccommend it as first language, but you have to read it often enough)
as well as the idea of non-IO-blocking servers, which consume less resources and
still have good perf. Gets you thinking about other/better ways to utilize the hardware.

regards

thomas