Linked by Thom Holwerda on Thu 27th Dec 2012 19:50 UTC
Permalink for comment 546543
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/22/13 22:23 UTC
Linked by Thom Holwerda on 05/22/13 13:38 UTC
Linked by Thom Holwerda on 05/22/13 13:30 UTC, submitted by JRepin
Linked by Thom Holwerda on 05/21/13 22:06 UTC
Linked by Thom Holwerda on 05/21/13 21:45 UTC
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
More News »
Sponsored Links



Member since:
2007-04-18
There's an MSO.DLL and an MSORES.DLL that collectively take up 210 MB of RAM.
It's nice to focus on DLLs, but I also said "and a host of other resources". What I mean specifically under that heading is, for instance, garbage collector cruft, i.e. uncollected objects. Even a small GC program can easily accumulate hundreds of megabytes of RSS before the garbage collectors bothers doing something about it.
I know, that's why I was talking about shared libraries.
I'm fairly certain they are paged at larger increments than that, otherwise the initial execution would be so exceedingly slow that even startup would take minutes to complete. What most likely happens (and I'm simply talking from *nix kernel experience, so feel free to correct me) is that the I/O subsystem pulls the files in in much larger chunks into the I/O buffer cache. Subsequent mapping of pages happens much faster (via process page table manipulation), but the blocks holding the DLL contents still take up space in the page cache, although much less than pulling it in completely in one go and also in an evictable manner subject to other kinds of memory pressure.
And that is a positive point how exactly? Also, most UI icons, I would hope, are not 256x256x32bpp.
A good-sized compressed TTF font is a few MB in size, at most. Unless there is a couple thousand fonts hidden in office somewhere, this contributes a few dozen MBs at most.
Depends. If it's a GUI with controls and some live code behind it, I would give it 10MB of extra. Given some icons and help pages, perhaps 30-40MB.
New code: 3-4 MB (if the layout engine is really, really big, like 500KLOCs+).
How much space do their definitions/code take on disk?
I'm sorry, but now you're into the silly things. This is just a bunch of interpreted code. Perhaps, and now I'm being very generous here, 10MB of new code, 30MB tops. I mean it's not like they re-implemented the entire office suite in it, they just added some utility functions.
So in summary, you're still only 1/10th the way. I know where the 9/10ths went - it's the animated sequences, the uncompressed BMPs on disk, the tons of various pre-made media, like music and video stuff for shit business presentations that nobody likes anyway. If you took it away, I doubt anybody would really complain, but then you wouldn't have the latest and greatest incremental update to sell to your locked-in business customers. There's money to be made!