About | Buy Stuff | News | Products | Rants | Search | Security
Home » Resources » Rants

Bloat Dissections II Follow Up

Week of June 8, 2000

thought, n. Middle English thenken, from Old English thencan; akin to Old High German denken to think, Latin tongere to know. To form or have in the mind, to call to mind, to devise in the mind, to subject to the processes of logical thought.

The above mentioned article in RISKS Digest caused astute comment (all RISKS articles do - it's a testimony to the people who read the articles), and most of these comments point to the fact that unsung heroes have been fighting bloat since computer time immemorial.

Bloat is often associated with - and blamed on - the commercial PC software industry that blossomed in the 1990's, but the exigencies of this market have not forced vendors to produce shoddy products. No - for that, as these letters will indicate, you need mental laziness and pure ignorance in addition to the 'who cares?' and 'we don't have time!' attitudes.


Liked the posting on Bloatware.

My biggest experience was inheriting a monster of an application, although it had a smaller user base than regclean.

The program was being ported from mainframe to Unix workstations.

The mainframe version had had to be run in a specially configured environment to avoid problems with internal 16Mb, and other limits. (Don't you love MVS?!)

The HP version - not quite working - had a 7Mb executable - and a minimum run time size of 12 Mb (not massively excessive as it was dealing with large chunks of data).

As mainframe fortran 77 code it did static memory allocation - this was the source of most of the bloat.

The fix was a tad more than 10 minutes - I had to identify every function that relied on data being saved in memory during a previous execution of the same routine. For each of these I dropped in a compiler directive to allocate just this function's data statically.

Executable size dropped from 7 to 3 - minimum run time size dropped from 12 to 7.

More importantly - because the compiler now knew it didn't need to save the results of its computations back to memory - it could drop a lot of store statements, and spot more redundant code.

Performance roughly doubled.

Worst runtime bloat example I've seen was a fortran 77 library that in order to overcome issues of static memory allocation allocated 26 MB of common storage at start up. The library was also compiled with static allocation. A simple contour of this grid of 60,000 data points linked with the library would produce a 3Mb executable that ate 30MB of RAM on execution. You'd watch the load meter hit the roof, followed by the memory being paged out to disk... And they didn't understand why I thought it sucked.

Some of this is down to laziness - but most of it is down to ignorance I suspect.

Possibly some is down to lazy thinking - probably never occurred to them that the user might like to use another application along side this one. Which was the main reason for my optimisations of the monster above.

Simon Waters
Eighth Layer Limited


Someone at our company wrote a short MS Word document (just a handful of pages) and emailed it, as an attachment, to several people in the company. The document contained several screenshots. For some reason, MS Word stores these images in a *completely* uncompressed format. The result was a 20Mb document which expanded into a 26Mb email message. This message was too big to be delivered via modem: the pop3 server kept timing out after about 20Mb worth.

The kicker is that when I finally downloaded the document via a fast internet connection and ran gzip on it, it compressed down to just 180Kb! That's a factor of over 100 to 1 compression from just a few seconds of effort.

With just a few mouse clicks you can bloat your word document to multi-megabyte network-spamming size and send it to hundreds of mail boxes. There are any number of lossless image compression formats, plus any number of general purpose file compression algorithms, any of which would make a huge improvement. Even the dumbest run length encoding would make a big difference on a screenshot. But Microsoft just doesn't care:

(*) Their image file format doesn't compress images;
(*) MS Word doesn't compress files when it stores them;
(*) Email attachments are not compressed.

As RA Downes says:
> It's professional pride on the one side -- and 'who cares?' on the other.

Martin Ward University of Durham

About | Buy | News | Products | Rants | Search | Security
Copyright © Radsoft. All rights reserved.