And to clarify... readdir may be faster than getattrlistbulk if all you need 
are the names. If you call getattrlist (or lstat) on every item you get back 
from readdir, you'll find that getattrlistbulk is faster.

- Jim

> On Dec 10, 2014, at 4:57 PM, Eric Tamura <etam...@apple.com> wrote:
> 
> It should be much faster.
> 
> Also note that as of Yosemite, we have added a new API: getattrlistbulk(2), 
> which is like getdirentriesattr(), but supported in VFS for all filesystems.  
> getdirentriesattr() is now deprecated. 
> 
> The main advantage of the bulk call is that we can return results in most 
> cases without having to create a vnode in-kernel, which saves on I/O:  HFS+ 
> on-disk layout is such that all of the directory entries in a given directory 
> are clustered together and we can get multiple directory entries from the 
> same cached on-disk blocks.
> 
> How big are the directories in question? How many times are you calling this?
> 
> Eric
> 
> 
> 
>> On 10 Dec 2014, at 4:32 PM, Sean Farley <sean.michael.far...@gmail.com> 
>> wrote:
>> 
>> Hello HFS+ devs :-)
>> 
>> I was playing around with trying to speed up the status operation in
>> mercurial on HFS+ filesystems and heard that getdirentriesattr might be
>> faster.
>> 
>> From what I could gather (man pages and online resources), it seems the
>> potential speedup comes from the ability to do a bulk call on the files,
>> though correct me if I'm wrong.
>> 
>> I posted a proof-of-concept patch here:
>> 
>> http://www.selenic.com/pipermail/mercurial-devel/2014-September/061777.html
>> 
>> But got no real results. Experiments tried included: warm cache vs cold
>> cache, numbers of files to batch call, and combinations thereof.
>> 
>> Am I missing something obvious or just looking in the wrong place?
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Filesystem-dev mailing list      (Filesystem-dev@lists.apple.com)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/filesystem-dev/etamura%40apple.com
>> 
>> This email sent to etam...@apple.com
> 
> 
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Filesystem-dev mailing list      (Filesystem-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/filesystem-dev/luther.j%40apple.com
> 
> This email sent to luthe...@apple.com


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list      (Filesystem-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to