On Thu, Oct 10, 2002 at 01:10:55PM -0700, Andy Ross wrote: > Curtis L. Olson wrote: > > Just a couple thoughts to consider. We are looking at 16-20,000 > > airports so we couldn't stuff them all in a single directory. Even > > splitting them into subdirectories by first letter probably isn't > > enough. > > There are 17073 airports in the current database. Splitting on first > letter only, the largest is (no surprise) 'K', with 2161 airports. On > a lark, I created such a directory containing all the US airports. > The creation process was relatively slow -- 20 seconds or so. But > once the files are there, access to them is very fast (a few tenths of > a second). This was true even after I was careful to flush the buffer > cache by cat'ing a different disk to /dev/null, if the stuff is in the > cache, of course, access is milliseconds at most. If you think about > it, 2000 is about the same number as the number of device files in > /dev, and no is complaining about performance issues there. > One thing to note here is that all this cache take up RAM, and will be dropped on the floor as soon as there's any memory pressure. As it stands, on a 128MB system FlightGear will probably push most of that data out with it's own memory use, let alone leaving space for any other apps . . . So you'd likely get large performance deltas for this system depending on many subtle issues in the VM and VFS. At least using our own code would allow us to make things consistent . . .
Not that I think it's a bad idea at all, though, particularly for the future: under Linux at least there are a number of new developments in filesystem-land that will make using this kind of thing much easier. ReiserFS is specifically designed for that kind of thing, and ext3 with the directory index performs as well or better on large directories. XFS probably handles such things fairly well, too. Reiser has tail packing, though at a performance cost, and there's some talk of adding tail packing to ext3. The problem is, FlightGear is portable, and most of these new features are Linux-only, and linux-2.4.$BIGNUM or 2.5+ only . . . Performing well under Linux with ReiserFS is a good advertisement for Linux and ReiserFS, but not so good for FlightGear if that's /all/ we perform well under. <snippage> > the size of the scenery. Remember that with a file per airport, there > is no need to have the whole airport database in the base package. > You can download the airports along with the scenery. Airports aren't > very useful without scenery, anyway. > I rather like the idea of the airport files being /part/ of the scenery. It certainly seems to be where they'd belong, logically speaking. It'd also mean that the airports in the scenery matched perfectly the airports that FlightGear sees when running (unless you've explicitly hacked things up) - there've been several reports of runways and their navaids being completely out of sync with the scenery, and this seems like a good way to fix them . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/
msg08800/pgp00000.pgp
Description: PGP signature
