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/