Hi! Ralph Glasstetter wrote:
>>>PS: Has disabling the mmap part under windows any disadvantages? >> >>I'm not sure if mmap ever had any advantages on Windows at all, compared >>to read. >> >>On Linux/Unix, I would claim that mmap is a little faster (but not >>much). On Windows, the difference in performance (if there is any) >>doesn't matter because mmap didn't work correctly in the first place. >>But if someone can provide a working implementation (in particular, one >>that also works with files >= 2 GB), we can turn mmap on again and compare. >> > > OK, if it's just an neglectable performance issue it doesn't really matters > if switched off... > just wondered that you could easily switch it off by just disabling 20 > consecutive lines of code. ;-) In dvbcut, use of mmap() has always been optional. When the mapping failed, it reverted to malloc() and read(). Therefore, mmap() was rather easy to turn off :-) >>Note that mmap isn't optimal either. What I really would like to try is >>direct disk access (O_DIRECT) on Linux. Unlike raw device access, it >>still reads/writes files (with some alignment restrictions), but it >>doesn't cache the data. > > > Yeah, that could give a boost in performance... > > Found a nice IBM article on that issue (for AIX): > http://www.ibm.com/developerworks/aix/library/au-DirectIO.html > > But there (on AIX) you have to enable this additionally by a mount option, > which is not really > practical for our application. But I don't know how that is implemented under > linux... All you have to do is pass O_DIRECT as an additional flag to open(), and make sure your buffers and read() calls are page aligned. > Also you may have to read (sequentially) larger chunks of data, since you > don't > benefit anymore from read-ahead algorithms. Yep, we would have to do that "manually". On the other hand, if you're scrolling through the video in e.g. 1 or 10 minute intervals, you won't benefit from the standard read-ahead algorithm anyway, since it assumes sequential operation. It might be faster to guess the next read position (based on previous movements) and prefetch the data explicitly. > And this (http://kerneltrap.org/node/7563) containes a nice statement of > Mr.Linux against DIO! ;-) > Very funny... :-) I haven't used O_DIRECT in real world applications yet. But it turned out to be very useful to circumvent the cache when you're running storage benchmarks (which I do quite often). posix_fadvise(), on the other hand, is something we could try as well. In particular, the POSIX_FADV_DONTNEED flag might be useful in the (sequential) indexing and export phases. Not so much POSIX_FADV_SEQUENTIAL because it only doubles the read-ahead window but doesn't reduce the cache footprint. I guess I'll do a little testing with different modes. -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ DVBCUT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dvbcut-user
