Re: performance: use pread instead of lseek+read
От | Manfred Spraul |
---|---|
Тема | Re: performance: use pread instead of lseek+read |
Дата | |
Msg-id | 3E5A941E.3060901@colorfullife.com обсуждение исходный текст |
Ответ на | Re: performance: use pread instead of lseek+read (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: performance: use pread instead of lseek+read
|
Список | pgsql-patches |
Tom Lane wrote: >Manfred Spraul <manfred@colorfullife.com> writes: > > >>What about removing lseek entirely and using the p{read,write}? >> >> > >Portability. > >$ man pread >No manual entry for pread. > Which OS? google finds manpages for Tru64 4.0, HP UX 11i, solaris 8, aix 4.3 Linux has it since 2.2, FreeBSD at least since 4.0, it's even listed in the SVR-4 emulation of FreeBSD. >$ > >It seems unlikely to me that eliminating lseek on some platforms would >be worth the hassle of maintaining two code paths. lseek is mighty >cheap as system calls go. > It was considered expensive enough to write a syscall avoidance layer that caches the file pointer and skips lseek if fpos==offset. A kernel must perform quite a lot of parameter validation and synchronization - think about a multithreaded app where close and lseek could race. > > >>Attached is a patch vs the cvs tree. >>It seems to work - 7.3.2 with the patch applied passes the regression >> >> > >Can you measure any performance benefit? > > What would be an interesting benchmark? If you want a microbenchmark: lseek+read(,,8192) is around 10% slower than pread(,,,8192) with hot cpu caches on my Celeron Mobile Laptop. Linux-2.4.20. Read-ahead is impossible to answer without looking at the sources. Linux does readahead, actually read is implemented as pread(,,,file->f_pos). -- Manfred
В списке pgsql-patches по дате отправления: