FileManager Performance on OSX
FileManager Performance on OSX
- Subject: FileManager Performance on OSX
- From: Kent Clelland <email@hidden>
- Date: Fri, 4 Jun 2004 15:13:22 +0200
On Jun 3, 2004, at 9:47 PM, email@hidden wrote:
According to one of the authors of the Carbon File Manager, async reads
are no better than synchronous reads on X.
is this really true?
or to what extent is this true? OR what means "BETTER"??
does this mean that async reads are not async on X?
if I have an app which has 15 - 20 threads running around doing their
thing, one of those threads is responsible for reading data from disk.
5 other threads are blocked until the read thread is completed. if I
read async I would imagine that the amount of time that the 5 threads
are blocked is minimized. the data may not yet be ready, but the
threads shouldn't hang up waiting for a sync read operation to finish?
OR????
while we're on the topic of filemanager...
I want to ask also about WRITING (streaming) data to disk..
I've noticed that the async calls (PBWriteAsync) perform much better
(ie don't interrupt audio)
than the other write methods, even when boundary-ing on 4k blocks,
pumping up thread priorities, etc...
so the question is WHY?
and actually file io on X has become quite mysterious, no? I mean when
one is confronted with choosing between
fwrite
FSWrite
FSWriteFork
PBWriteSync
PBWriteAsync
one would imagine that at some point they would all get patched through
to a single call, no? and is that not actually a
PBBlah() call? docs are a little skimpy in this regards...
thanks for the info!
|K<
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.