> Well, depends. Non-mmap you have to do the storage management in the > app. mmap, you're using the storage management in the kernel to figure > out where the data goes, as well as all the LRU stuff to figure out > what happens when you're running out of memory and you need to get rid > of some of it.. Most kernels do a better job than most people at this > sort of thing (at least from code I've seen).
i haven't found this to be the case. in a former life, one i'd rather forget, i did full text search. in order to return the full text, we had to go get the document. due to the very crappy nature of ext2, it was not feasable to store the documents individually. they had to be bundled up in chunks of about 1gb. being young and easily distracted by shiny bits, i decided to use mmap. to my shock and horror, this turned out to be really slow. so then i modified the mmap to only map part of the file. this was faster, but the speed of this operation was strongly influenced by the size of the file. if i had been even moderately smart, i would have just read the part of the file i needed. it would have been much, much faster. as to using mmap for memory management, that confuses me. it's like saying the os should provide linked lists, because developers can't do it. isn't part of the argument here that applications know better how to manage buffers? personally, i suspect the reason the unix guys need mmap, is to support 100mb of shared libraries for firefox. if you want mmap, why not start over with something like multics. then you can get rid of the annoying file abstraction all together. (of course, disagreeing with ken can be a dangerous business.) - erik
