On Apr 23 07:36, Eric Blake wrote: > But there are a number of applications out there that behave more > efficiently if d_ino/d_type ARE properly implemented. For example, both > coreutils and findutils are smart enough to avoid extra [l]stat()s on > systems with working d_type when traversing directories. You may find > that properly implementing d_type slows down readdir() but speeds up > applications. Most applications that use readdir() are doing so in the
Let's assume we implement d_type. It's not just done with implementing DT_REG and DT_DIR, you would also have to implement DT_CHR, DT_SOCK, DT_FIFO, etc. All of these require to open the file and read it(!) to find out what type they are. This is a pretty nasty slowdown in readdir. > Most applications that use readdir() are doing so in the > context of directory traversal, and have to do a followup stat or lstat to > find out the type if readdir() doesn't tell them. I'm pretty confident that this assumption is incorrect and one reason for this is that d_type isn't even mentioned once in the standards. Also, some of the most important applications, ls(1) or find(1) wouldn't be sped up, but slowed down if you specify any additional information flag as, say, -l for ls, or anything except -type or -name for find. The effect would be that you slow down most applications which use readdir/stat, to speed up a couple of corner cases. Actually, I'm not entirely against implementing d_type, but as far as I can see, it's not done with implementing it and forget about it. If you want a *real* speed up, you would have to take measures, so that the same information isn't retrieved over and over again. For instance, if each call to readdir or stat would store the information in a stat-cache, then later calls on the same file could get the information from the cache. However, that's just a rough idea with a couple of caveats, so don't expect any quick change. As long as we don't have something like this, I would not like to see d_type implemented. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
