public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: eCos@sunnorth.com.cn
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] A question about function readdir and stat
Date: Fri, 28 Mar 2008 13:52:00 -0000	[thread overview]
Message-ID: <20080328093143.GA29054@lunn.ch> (raw)
In-Reply-To: <OF60B0EC03.C829415A-ON4825741A.00316149-4825741A.0031CFA4@sunnorth.com.cn>

On Fri, Mar 28, 2008 at 05:04:04PM +0800, eCos@sunnorth.com.cn wrote:
> Dear all??
> We have to do a total sd card scanning and check for some certain type of 
> files in our application, some application code is as below:
> 
> -----------------------------------------------
> DIR *d;
> struct dirent *de;
> struct stat s;
> d = opendir("/");
> while((de = readdir(d)) != NULL)
> {
>         stat(de->d_name,&s);
>         ...
> }
> -----------------------------------------------
> In order to accomplish the purpose, we have to call stat function to 
> distinguish file and directories, i.e. stat(de->d_name, &s), however, this 
> does makes speep slow.
> 
> Suppose that we have nearly 10000 files on our sd card root directory, so 
> root directory has entries:
> ..
> .
> f1
> f2
> f3
> ......
> f10000
> ......

Why not impose a directory structure. eg my camera has a directory for
every 100 images. That would mean you only need a maximum of 100
comparisons for the last file in the directory and for 10000 files you
need 100 directories.

Another option which would give a speed up is not to use numbers, but
a more dense naming scheme. eg fAA, fAB, fAC, ..., fAZ, fAa, ... fAz,
You still end up doing 10000 comparisons, but the strings you are
comparing are shorted so there is less work to do.

> On linux, readdir's mannual 3, we found that the struct dirent has another 
> field named d_type, which is not in eCos(eCos has only one field d_name). 
> So on linux, when readdir returns a struct dirent, we could check the 
> d_type field to pass the direcoties,  without function stat's comparing 
> names with all the entries. Of course, using of d_type will harm the 
> portability of our program, but we could accept this fact.

I assume you are using fatfs? Looking at fatfs_fo_dirread, this would
be easy to implement. You have the information you need in dentry. So
just add the new member d_type and fill it in.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

      reply	other threads:[~2008-03-28  9:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-28  9:32 eCos
2008-03-28 13:52 ` Andrew Lunn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080328093143.GA29054@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=eCos@sunnorth.com.cn \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).