Simon Fowler wrote: > 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.
Right, which is why I was careful to cite numbers that reflected actual disk I/O, and not cache performance. Even hitting the disk, performance is acceptable. If "most" machines are faster than that, it's a bug not a feature. :) > 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. I think you have perhaps misinterpreted. My point was that a blunderingly simple file-per-airport scheme was adequate on all filesystems, not that it required fancy stuff. The reiserfs note was a fun bit of trivia about how OS authors try to accomodate stuff like this. If we work everywhere, but are blazingly fast (or take up far less space) under linux/reiserfs, I'd again consider that a feature and not a bug. > 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. [...] 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. Right. The only complication is that there's an existing use case that requires doing fast lookup of airports by ID. My idea was to distribute files with the scenery and drop them in a single global directory. Trivially simple to implement and maintain -- users who discover airport or navaid bugs can just fix the file and post it to the mailing list; they don't need any coding experience at all. Andy -- Andrew J. Ross NextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
