Date: Tue, 12 Nov 1996 11:35:50 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: proff@suburbia.net (Julian Assange) Cc: jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: predictor-clues [was ufs too slow?] Message-ID: <199611121835.LAA20668@phaeton.artisoft.com> In-Reply-To: <199611121020.VAA30753@suburbia.net> from "Julian Assange" at Nov 12, 96 09:20:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> One thing that never ceases to annoy me about current opperating systems, > API's and compilers is the lack of support for predictor-clues. > > File system layout could be hugely optimised if open had predictor-clues > such as "expected file size", "average read/write size", > "sequential/random access factor", "minimal time response" etc. One thing that has always annoyed me about X11, Windows, and Macintosh is that they expect the application to do their work for them. Specifically, I can never be *guaranteed* backing store for graphics data for an occluded window; as a result, the application must redraw the image on expose events. Never mind that it took me 12 hours to generate the image in the first place. So every application, with the random *infrequent* exception that they were apparently optimizing for, has to do its own double buffering. As a result, there is no standard method for doing the damn thing, even though it's the most frequent thing anyone ever wants to do. Further, it means I have to jerk around with color maps and square root my colors (total bits minus one bit over two, round down) to get minimal scrolling dual playfield effects (as in ACM). The reason I mention this is that the default behaviour should be optimized for the most common case. In most cases, this means *not* using predictors even if they exist, because the default handles it for us like it's supposed to. In rare (non-default) cases, this means using madvise(). Feel free to make an OpenFile(3) that calls the appropriate open(2) and then ioctl(), madvise(), whatever, to it's hearts content. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611121835.LAA20668>