On Wed, 2009-11-11 at 03:50 +1030, Tim wrote: > On Tue, 2009-11-10 at 23:47 +1100, David Timms wrote: > > Things to think about: > > - if you are talking about the same machine, disk drive tiredness > > would have reduced the access speed that you can achieve, when r/w to > > disk. > > Beg yours... drive tiredness? The old gray mare not what she used to > be? Since when do drives become old age pensioners with blankets on > their laps, day dreaming about the old days, instead of doing the same > as they were doing last week? Since they use sector remapping to recover failed errors and ECC/parity codes to recover data errors. As sectors have to be remapped elsewhere on disk seek overheads will increase. There may also be further penalties as the recoverable media error rate rises, i.e. the disk has to issue repeated reads to correctly retrieve the data for a particular sector. Sometimes you'll see this acutely when a sector is failing - the drive will appear to go out to lunch for a moment when the tricky sector is accessed. If spare sectors are still available a write to the offending location may cause the drive to spare it out and avoid the problem for a while. Looking at the S.M.A.R.T. reports for the drive can help you understand if this is the problem for a particular system. Often though I've seen users diagnose a problem like this as "old hardware getting slow" when in fact it's a software or file system issue. > > - more stuff relying on storage/retrieval of information from > > inefficient storage formats like xml > > Reminds me of back when I was using an Amiga - any program that stored > its configuration in a text file took ages to parse it as the program > started up. Whereas those that stored their data in the programs binary > format were very nippy. > > Even now, on fast GHz CPUs, I've noticed that you can get Apache or > Squid to start up much quicker if you purged the masses of comments out > of the configuration file, so the program had less to parse. > > Yes, the programs do parse the comments, they've got to find the end of > the comment to find the next instructions that they're going to use, the > whole file is parsed. Depends how you look at it - most comment notations have a line-delimiter (e.g. # in apache). This only requires examining the first character of the line to know that the rest must be ignored (of course the entire line must still be read into memory which does impose overhead especially if there are many lines of commentary as is often the case for default config files). Block comments do require consuming characters until the end-of-comment token is reached. > Computer users nightmare number 9: Part way through the installation > process, a message pops up, "You're going to need a bigger boat" Nice way of putting it! Regards, Bryn. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
