Messages in this thread | | | From | "Lou Grinzo" <> | Subject | Another way | Date | Tue, 6 Jul 1999 09:16:24 -0400 |
| |
Jamie Lokier mentioned other possible ways to do a user-space file conglomeration. One possibility that I don't think I've heard anyone else mention, is exploiting the large amount of memory on some systems.
If the system has enough memory available, the userland lib can read the whole file into memory upon open, hold the file open, make changes in memory, and only write them out on an explicit flush or close. This eliminates the waste of Word's fast save and dead space, and can be quite quick.
This obviously only helps when you have enough memory available, and it's not hard to cook up pathological cases, e.g. the user opens a file like this, and then fires up several other memory eaters, and the system swaps itself to death.
The implementation would need some serious smarts to avoid these problems, and would probably rely on correct hints from the app, like an indication of the expected activity or whether to do the in-memory thing at all, or even use a timer to regularly examine the memory situation and flip from in-memory to on-disk modes automatically, if a threshold were reached.
Today we're seeing some desktop systems with a lot of memory, and this might be one way to make Linux and/or Linux apps smart enough to conditionally exploit that situation for the user's benefit, at least in some cases.
IMO, one mark of good design is figuring out how to exploit a plentiful and cheap resource, and RAM is, for many users today, in that category.
Although, with disk space getting ever cheaper, I'm not so sure that the wasted space in compound docs is such an evil thing. Sure, smaller docs are better, but does someone with a 9 or 16 or 20 or 37GB HD even notice that a document is 200KB when it should be only 100KB? (Given my militant positions on performance issues in the past, I find it hard to believe I'm saying this, but if you look at the systems people are buying today, I think it's clear that system design should reflect the shifting relative cost of hardware vs. usability and the user's time. If we do something that makes document files slightly larger (< 100% increase) but provides a significant usability boost or new feature when used, then that's probably an acceptable tradeoff in most cases. If the feature is optional (as Word's fast save is), then it becomes all the more viable.
(No flames about wasting the user's HD space, etc., please. No one here is more militant about respecting the user and his/her resources than I am. I'm merely pointing out that relative priorities shift as a function of changing economics, and that system design philosophy should evolve to reflect this, as well. It should evolve slowly, and with significant care to avoid problems or getting ahead of trends, but it should still change.)
Lou
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |