Erik Funkenbusch wrote:
> On Wed, 19 Jul 2006 16:53:03 +0100, BearItAll wrote:
>
>>> That's rich. Sun complaining that Office is 'memory loving'. Have they
>>> looked at OOo's memory consumption lately? It leaves office in the
>>> dust.
>>
>> When you open any one of the OO suite then it will take a fairly large
>> chunk of memory if it is available. But from then on you can launch as
>> many others as you like with no extra loss of resources.
>
> So in other words, even if you're only using the word processor, *ALL* the
> apps are loaded into memory. How efficient.
>
Every app has to deal with many of the same things. For example document
convertions, spell checker, file and directory access, and many more. Some
suites have in the past provided these for each of it's sub applications,
when it is a great deal more efficient to write one of each for the entire
suite.
That is far from inefficient.
MS do this is much the same way with their suite by the way, in fact it was
MS that first came up with the 'Every document is a database' approach, it
was a clever move and after they did it seemed so obvious that it was a
wonder no one had done it previously, so that the data handling of one part
could properly handle data of any other. The only other that might be said
to have beaten them to it was StarOffice, but that was more because the
parts of SO were intentionally created from the beginning as front ends
(views) on data.
>> It doesn't matter if much of the shared code ends up in virtual on a busy
>> machine or one with lower resources, it is still brought in much more
>> quickly from virtual than from disc.
>
> Then why does Sun complain about Office being 'memory hungry" if being
> memory hungry isn't a big deal?
MS Windows and UNIX/Linux memory handling are very different. This isn't
meant as an MS bashing session, the two were meant for different purposes.
UNIX on a mainframe in order to get the best speed for many users on
potentially many applications aimed to get more running from memory. It can
still discard if needed, first to virtual then completely. It also makes
extensive use of cacheing, which as we all know is the main reason that a
UNIX/Linux must be properly shut down rather than just turned off.
MS memory handling was initially for much lower memory allocations, because
it was being ran in lower resources. It also suffered for a time from DOS
and the basic PC architecture as far as extended memory was concerned,
because DOS was never written for a shared resource system it was very
wrong for MS Windows where for the first time on a PC you ran the risk of
more than one application accessing the same file at the same time. Add to
that that Windows was itself to be offering file services and DOS simply
could not used for that without risk.
So MS's hands were tied due to these historical items, they had to support
previous releases while at the same time knowing that they needed to get
away from the restraints of DOS.
So they changed us as programmers from the the old grab-n-lock memory
allocation, where you grab what you want and sod the rest of the system, to
references. By using references the OS is again free to manipulate the
memory. Once that was in place MS could redesign their memory handling.
Their memory model is still based in part on lower spec machines, smaller
blocks and a different approach to cacheing. But it can be easily argued
for either the Linux system or the MS system being the better for client
machines. Both arguments would be valid.
In hind sight it is easy to say MS could have graded the change better or
taken a different path, but really MS did quite well in that area. Keeping
in touch with an OS such as DOS while trying to head towards a more server
like file system can't have been easy to work out. I am glad though that
they are now heading away from ntfs, it was only meant as an interim file
system anyway being primarily a software based server file system.
|
|
