Mail Archives: cygwin/2009/09/02/10:33:31
On Tue, Sep 01, 2009 at 07:10:20PM -0600, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>According to Christopher Faylor on 9/1/2009 5:37 PM:
>> Maybe you mean d_namlen?
>
>Yes; serves me right for confusing readdir(2) and readdir(3) man pages.
>
>>It is not a given that adding d_reclen would speed anything up since it
>>cause every single program that uses dirent to effectively perform a
>>strlen on every record returned by readdir whether it needed that field
>>or not. Making sure that field was filled out would also complicate
>>Cygwin's internal logic.
>
>Not so. For example, fhandler_disk_file::readdir_helper is already doing
>a sys_wcstombs to populate the d_name buffer, and that returns the length
>as a side effect. In other words, the cost of providing the length to the
>client is an O(1) single assignment of an already-existing value per entry
>(and when you consider that we are already assigning __d_unused1 to 0,
>that means no net increase in cost to clients that don't care about the
>length); whereas the current situation requires clients that care about
>the length to use O(n) strlen() and duplicate something that was
>previously calculated by cygwin1.dll.
Ok, I shouldn't have said "every record". For disk files, The length is
even available in fname->Length. However, there are other places where
the length is not available and would have to be calculated. I know it's
a negligible cost but I'm not convinced that it is one worth taking.
(And, FWIW, setting a variable to zero is a very cheap operation)
Anyway, if we were going to do something like this, we'd make Cygwin
more like linux. It sets d_reclen to the size of the structure. There's
some more calculation for every readdir.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -