Early this year, Andy Kramek wrote about Writing better code (Part 1).
I just saw an example that I thought would be worth sharing.
This system was using a treeview with two different "purposes". One was to show a list of about 10 nodes and the other showed a list with about 200 nodes on it.
When the system ran, it just seemed super slow. The first list would appear fairly quickly but then when it switched between the two, it would reduce to a crawl, even just to show 10 nodes.
Why?
The loop looked like this:
SCAN
lnRec = RECNO()/RECCOUNT()*100
Treeview.Nodes.Add(xxx,xxx,xxx)
DOEVENTS
ShowProgress(lnRec)
ENDSCAN
DOEVENTS is useful for allowing any Windows activity to refresh - so it's useful to call it - but calling it within the SCAN means it will take a hit on performance as well as the ShowProgress for every record.
As Andy notes: "Inform your users, but don’t compromise performance to do so"
With a few minor tweaks, the code now runs incredibly fast and I was able to point the programmer in question to Andy's great post about it.
As I noted last week, these are the types of things that the development environment need to be catching to make us all better developers.
Kind of like having a Peer Review happening in real time.
Thanks Andy - once again for having great tips easily available!
I just saw an example that I thought would be worth sharing.
This system was using a treeview with two different "purposes". One was to show a list of about 10 nodes and the other showed a list with about 200 nodes on it.
When the system ran, it just seemed super slow. The first list would appear fairly quickly but then when it switched between the two, it would reduce to a crawl, even just to show 10 nodes.
Why?
The loop looked like this:
SCAN
lnRec = RECNO()/RECCOUNT()*100
Treeview.Nodes.Add(xxx,xxx,xxx)
DOEVENTS
ShowProgress(lnRec)
ENDSCAN
DOEVENTS is useful for allowing any Windows activity to refresh - so it's useful to call it - but calling it within the SCAN means it will take a hit on performance as well as the ShowProgress for every record.
As Andy notes: "Inform your users, but don’t compromise performance to do so"
With a few minor tweaks, the code now runs incredibly fast and I was able to point the programmer in question to Andy's great post about it.
As I noted last week, these are the types of things that the development environment need to be catching to make us all better developers.
Kind of like having a Peer Review happening in real time.
Thanks Andy - once again for having great tips easily available!
Comments