Finder Network Performance -- Fundamental Problems?
Possibly due to a faulty network connection, I was recently subjected to a problem I've heard about quite frequently. Upon my attempts to copy a file via AFP, the Finder entered several consecutive unresponsive states lasting up to approximately five minutes each.
"top" showed the finder as using no CPU time, so I surmised that the whole application was simply waiting for data it should not have assumed was coming. I'm not much of a programmer, but I thought I'd try opening Spin Control in case it would shed some light on what the Finder was doing during its periods of unresponsiveness.
According to Spin Control, the Finder usually had two or three threads running at these times. One thread would be spending several seconds, or even minutes, in one of three rather fundamental-sounding functions: open, close, or pread. The other threads would be waiting on mutexes as long as the main thread was stuck in open, close, or pread.
I only know some conceptual basics about concurrent programming, kernels or file systems, so I can't really take my "analysis" any further than that. As an OS X user, I'm interested in knowing why the Finder has these problems, if they can be fixed, and if so, when. Could these problems actually be solved by more artful programming in the Finder, or are they the result of underlying architectural problems that would defeat any current efforts to increase performance?
If anyone has any information or resources, I'd be quite thankful.
"top" showed the finder as using no CPU time, so I surmised that the whole application was simply waiting for data it should not have assumed was coming. I'm not much of a programmer, but I thought I'd try opening Spin Control in case it would shed some light on what the Finder was doing during its periods of unresponsiveness.
According to Spin Control, the Finder usually had two or three threads running at these times. One thread would be spending several seconds, or even minutes, in one of three rather fundamental-sounding functions: open, close, or pread. The other threads would be waiting on mutexes as long as the main thread was stuck in open, close, or pread.
I only know some conceptual basics about concurrent programming, kernels or file systems, so I can't really take my "analysis" any further than that. As an OS X user, I'm interested in knowing why the Finder has these problems, if they can be fixed, and if so, when. Could these problems actually be solved by more artful programming in the Finder, or are they the result of underlying architectural problems that would defeat any current efforts to increase performance?
If anyone has any information or resources, I'd be quite thankful.
Comments
Originally posted by Mac The Fork
One thread would be spending several seconds, or even minutes, in one of three rather fundamental-sounding functions: open, close, or pread. The other threads would be waiting on mutexes as long as the main thread was stuck in open, close, or pread.
Even without any concrete numbers I suspect the Finder is poorly threaded. Ideally, it should work like this (details aside): the Finder creates a thread per open window, so that when you open a folder on the network and bad things happen to the connection with that particular file share, one and only one thread freezes waiting for data (i.e. one and only one window becomes unresponsive). This way you could, say, either wait for a time out, or close the offending window or just ignore it and continue working with files in other windows. It may become more complicated with file copying, but I know that good apps don't freeze like the Finder when nothing fatal happens.
The Finder still behaves much like in OS 9 - if errors occur with a network connection, it simply stalls.