Re: [HACKERS] Sequential scan speed, mmap, disk i/o

Bruce Momjian wrote:
> In fact,
> mmap() is very slow, perhaps because you are changing the process
> virtual table maps for each chunk you read in, and faulting them in,
> rather than using the file system for I/O.

Huh, very slow? I wouldn't agree. I rewrote your mmap program to allow
for using reads or mmaps.

I tested it on 111MB file. I decided to use 8192 bytes buffer size
(standard postgres page size). My system is Linux, P166, 64MBs of RAM
(note that I have a lot of software running currently so the cache size
is less than 25MBs. I also changed the for(j..) step size to j+=256 just
to make sure that it won't influence the results too much and you will
see the difference better. mmap was run with (PROT_READ, MAP_SHARED)

Average results are (for sequential reading):
Using reads: total time - 21.39 (0.44user, 6.09system, 31%CPU)
Using mmaps: total time - 21.10 (0.57user, 4.92system, 25%CPU)

Note, that in case of reads the program spends much more time in system
calls and uses more CPU. You may notice that in case of Linux using mmap
is about 20% cheapper than read. In case of random reading it's slightly
more than 20% as I remember. Total time is in both cases similiar since
the throughput limit of my HD.

BTW. Are you sure, that your program was counting mmaps properly? When I
run it on my system it counts much more than what it should. On my
system offset crossed over file's boundary then it worked a minute or
more before it stopped. I attach my version (with hardcoded 111MBs file
size to prevent it, of course you may change it)

Mike

--
WWW: http://www.lodz.pdi.net/~mimo tel: Int. Acc. Code + 48 42 148340
add: Michal Mosiewicz * Bugaj 66 m.54 * 95-200 Pabianice * POLAND