Narrowing down a other speed issues; here's what I'm looking at now:
cls out of cache for large directories is slow.
The major problem is that the directory list is parsed every time, out
of cache. The ideal solution would be to cache parsed lists, too (and
having classes of cache objects could be useful, ie cached FileSets),
but that would mean ls and cls couldn't share cache. Anyway, in the
interests of not coding that :) the major problem is:
if(strlen(t)==5)
{
sscanf(t,"%2d:%2d",&date.tm_hour,&date.tm_min);
time_t curr=time(0);
struct tm &now=*localtime(&curr);
date.tm_year=now.tm_year;
if(date.tm_mon*64+date.tm_mday>now.tm_mon*64+now.tm_mday)
date.tm_year--;
}
localtime() is the bottleneck.
First, is there a reason this isn't
struct tm &now=*localtime(&SMTask::now);
No real speed difference, it's just simpler.
localtime() could be eliminated by caching now_tm in SMTask (along with
now and now_ms); doing a localtime in the main scheduling loop (in
update_now()) is cheap, instead of doing it in this time-critical inner
function. Any better ideas? (This depends on there not being any
obscure reasons not to use SMTask::now.)
There are other minor speed problems in this function, but that's the
dominant one. I havn't looked at the other parsers at all.
The ColumnOutput is also a minor speed hit: it does a brute force to
figure out the width of each column. I've changed that to a binary
search, but I want to test it more before submitting it. (On my p2/450,
10000 files on a 158-column screen takes about 100ms to run
get_print_info; it's about 20ms now. That's a lot, considering a lot of
people FTP from much slower machines than that; it won't help if the
parsing can't be streamlined, though.)
--
Glenn Maynard
