• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update")
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update")


  • Subject: Re: Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update")
  • From: Alastair Houghton <email@hidden>
  • Date: Sat, 3 Apr 2004 13:57:35 +0100

On 3 Apr 2004, at 07:25, mathew wrote:

> Anyone feel like doing some speed comparisons between Cocoa, Carbon and
> BSD for trawling every folder on a big hard disk, to put this one to
> rest?

Some figures I just obtained for a search of every file and directory
on my hard disk:

Carbon (using FSCatalogSearch) 54.9 seconds
Cocoa (using NSDirectoryEnumerator) 148.1 seconds
BSD (using opendir(), readdir() et al.) 129.1 seconds

It's also worth pointing-out that the Cocoa program only used a single
autorelease pool (I've got plenty of RAM ;->), and as a result took
several seconds to terminate. I didn't include the autorelease pool in
the timings for the Cocoa program.

Just out of interest, I made a couple of variants of the Cocoa program,
one of which used IMP caching, and another that used IMP caching and an
autorelease pool that was released every 10,000 -nextObject calls.
These two produced the following results:

Cocoa (IMP caching) 148.3 seconds
Cocoa (Inner autorelease pool) 143.1 seconds

The differences are well within the error bounds of this experiment; to
give some idea, subsequent runs of the IMP-caching variant returned
results of 143.5 and 142.9 seconds respectively, and a subsequent run
of the original Cocoa program took 143.1 seconds. The fact that all
three Cocoa variants performed similarly (other than at termination
time for the first variant) should be of no surprise; this operation is
almost certainly dominated by I/O overheads.

I didn't try the searchfs() API; I don't imagine that the result would
be too much different from the Carbon figure.

Kind regards,

Alastair.

--
http://www.alastairs-place.net

[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.


  • Follow-Ups:
    • Re: Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update")
      • From: Daniel Waylonis <email@hidden>
References: 
 >Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update") (From: mathew <email@hidden>)

  • Prev by Date: Re: Lockup Problem with Progress Indicator
  • Next by Date: Re: Line separator - root problem
  • Previous by thread: Re: Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update")
  • Next by thread: Re: Fast file access (was Re: [ANN] Shovel - Third-Party "Software Update")
  • Index(es):
    • Date
    • Thread