[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] new command lacks lock
From: |
Ken Hornstein |
Subject: |
Re: [Nmh-workers] new command lacks lock |
Date: |
Mon, 14 Oct 2013 18:26:51 -0400 |
>Even on local disk, I expect it makes a noticeable difference. Right
>now it takes 0.009s to run, with 940,047 files in 282 directories,
>11,994 unread total.
Ok, but it sounds like you're not scanning all of those directories, right?
I am not interested in having a feature regression, but I am wondering
how bad this really is nowadays. How long does it take to do a "ls" on
all of those folders? (Assuming you're not running a "ls" that requires
a stat() on each file, of course). I use AFS over the Internet, and
some quick tests suggests to me that even in that case readdir() is
pretty quick. If it's still lousy for you, then I'm willing to just
leave it as-is. Although maybe it would make sense to expose some of the
APIs so the routines to read the sequence files could be used, rather
than duplicating code (hm, maybe they are already?).
--Ken
- [Nmh-workers] new command lacks lock, Harvey Eneman, 2013/10/12
- Re: [Nmh-workers] new command lacks lock, Ken Hornstein, 2013/10/13
- Re: [Nmh-workers] new command lacks lock, epg, 2013/10/14
- Re: [Nmh-workers] new command lacks lock,
Ken Hornstein <=
- Re: [Nmh-workers] new command lacks lock, Eric Gillespie, 2013/10/16
- Re: [Nmh-workers] new command lacks lock, Ken Hornstein, 2013/10/14
- Re: [Nmh-workers] new command lacks lock, Ralph Corderoy, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Ken Hornstein, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Ralph Corderoy, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Ken Hornstein, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Ralph Corderoy, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Robert Elz, 2013/10/17
- Re: [Nmh-workers] new command lacks lock, Ralph Corderoy, 2013/10/17