From: "Daniel P. Zepeda" Date: 2002-06-15T13:26:11+09:00 Subject: Re: Are Unix tools just slow? On Sat, 15 Jun 2002 07:14:38 +0900 Chris Gehlker wrote: > Awhile back I was asking for help with a unixy way to search the mounted > volumes on my OSX machine for executable files. With help from you all, > I came up with a system call that worked but it was taking over two > minutes. What system call? > > I decided that I couldn't live with that so I rewrote the routine in > fairly high level C (no parameter block stuff -- all done with > FSIterators). > > My first working version, debug code and all, runs in about 0.2 seconds. I think we're talking about apples and oranges here. Your code walks the entire filesystem tree in two tenths of a second? I think not. Maybe you did a find or somesuch first that cached the filesystem information in memory, and then you called your C code? I'd like to know what the timing results for your C code are on a freshly rebooted system. > > On this old box, > sudo find / > /dev/null > Takes 61 seconds so I don't have any hope of avoiding the C code. Again, if you do a 'find /' once, it is going to take a long time, but do it again, on a mahine with sufficient memory, it is going to be pretty fast because the info is buffered in memory. > > It got me wondering, though. Are the unix file inquiry tools just really > slow on Mac OSX or are they slow everywhere? Did Unix sacrifice > efficiency for portability? No. I must admit that I haven't used OS X, but doing a find over the entire filesystem of similar sizes on a Windows machine and on a Unix box gives similar timing results. Actually, my informal testing shows the Unix box to be faster, but this is by no means a scientifically-arrived at result, just a shooting-from-the-hip test. I guess my real contribution to this thread: I recently saw a post about Ruby FAM. I thought it would be cool to write a tool that kept the filesystem information in an RDBMS, like PostgreSQL, using FAM to keep it updated, and also giving the ability to update the actual filesystem when the database is updated. It would be really fast and easy to use with a lot more features when compared to slocate. I've started to give it a shot, but what do you all think? -- "Daniel P. Zepeda" (Remove commas for address)