General > QB64 Discussion
QB64, Assembly, and Software Bloat
fatman2021:
Software bloat
Software bloat is a process whereby successive versions of a computer program include an increasing proportion of unnecessary features that are not used by end users, or generally use more system resources than necessary, while offering little or no benefit to its users.
Causes
Software developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. Achieving this efficiency was one of the highest values of computer programmers, and the best programs were often called "elegant;" —seen as a form of high art.
This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities. In part, this is because technological advances have since increased processing capacity and storage density by orders of magnitude, while reducing the relative costs by similar orders of magnitude (see Moore's Law). Additionally, the spread of computers through all levels of business and home life has produced a software industry many times larger than it was in the 1970s. Programs are now usually churned out by teams, directed by committees in software factories where each programmer works on only a part of the whole, on one or more subroutine. Thus today; the highest value is often the adherence to a predetermined structure that makes it compliant, —with subroutines as interchangeable as piston rods. Inelegant, even sloppy code is to some degree hidden from the end users by the increasing brute force and speed of modern computers. (There is little payoff to say, ...increase the speed of a sloppy five-millisecond subroutine —even by a factor of 100.)
Finally, software development tools and approaches often result in changes throughout a program to accommodate each feature, leading to a large-scale inclusion of code which affects the main operation of the software, and is required in order to support functions that themselves may be only rarely used. In particular, the advances in resources available have led to tools which allow easier development of code, again; with less priority given to end efficiency.
Another cause of bloat is independently competing standards and products, which can create a demand for integration. There are now more operating systems, browsers, protocols, and storage formats than there were before, causing bloat in programs due to interoperability issues. For example, a program that once could only save in text format is now demanded to save in HTML, XML, XLS, CSV, PDF, DOC, and other formats.
Niklaus Wirth has summed up the situation in Wirth's Law, which states that software speed is decreasing more quickly than hardware speed is increasing.
In his 2001 essay Strategy Letter IV: Bloatware and the 80/20 Myth, Joel Spolsky argues that while 80% of the users only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss the one or two special features that are present in the "bloated" version. Spolsky sums the article with a quote by Jamie Zawinski referring to the Mozilla Application Suite (which later became Netscape):
"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla."
Software bloat may also be a symptom of the second-system effect, described by Fred Brooks in The Mythical Man-Month.
Examples
Apple's iTunes has been accused of being bloated as part of its efforts to turn it from a program that plays media to an e-commerce and advertising platform, with former PC World editor Ed Bott, author of 25 books on Microsoft Windows and Office, accusing the company of hypocrisy in its advertising attacks on Windows for similar practices.
Microsoft Windows has also been criticized as being bloated - with reference to Windows Vista, Microsoft engineer Eric Traut commented that "A lot of people think of Windows as this large, bloated operating system, and that's maybe a fair characterization, I have to admit. ... But at its core, the kernel, and the components that make up the very core of the operating system, is actually pretty streamlined." Former PC World editor Ed Bott has expressed skepticism, noting that almost every single operating system that Microsoft has ever sold had been criticized as 'bloated' when it first came out; even those now regarded as the exact opposite, such as MS-DOS.
CD- and DVD-burning applications such as Nero Burning ROM have become criticized for being bloated. Superfluous features not specifically tailored to the end user are sometimes installed by default through express setups.
A number of technology blogs have also covered the issue of increased bloatware on cell phones. However, they refer to a different issue, specifically that of wireless carriers loading phones with software that, in many cases, cannot be easily deleted, if at all. This has been most frequently cited with respect to Android devices, although this phenomenon exists on phones running many other operating systems.
Alternatives to software bloat
Some applications, such as Mozilla Firefox and Winamp, package additional functionality in plug-ins, extensions or add-ons which are downloaded separately from the main application. These can be created by the software developer and often by third parties. Plug-ins enable extra functionality which might have otherwise been packaged in the main program.
Allowing extensions reduces the space used on any one machine, because even though the application plus the "plug-in interface" plus all the plug-ins is larger than the same functionality compiled into one monolithic application, it allows each user to install only the particular add-on features required by that user, rather than force every user to install a much larger monolithic application that includes 100% of the available features.
Open source software may use a similar technique using preprocessor directives to selectively include features at compile time. This is easier to implement than a plugin system, but has the disadvantage that a user who wants a specific set of features must compile the program from source.
Sometimes software becomes bloated because of "creeping featurism" (Zawinski's Law of Software Envelopment), also called bullet-point engineering. One way to reduce that kind of bloat is described by the Unix philosophy: "Write programs that do one thing and do it well".
Code bloat
Code bloat is the production of code that is perceived as unnecessarily long, slow, or otherwise wasteful of resources. Code bloat can be caused by inadequacies in the language in which the code is written, inadequacies in the compiler used to compile the code, or by a programmer. Therefore, code bloat generally refers to source code size (as produced by the programmer), but sometimes is used to refer instead to the generated code size or even the binary file size.
Common causes
Often, bloated code can result from a programmer who simply uses more lines of code than the optimal solution to a problem.
Some reasons for programmer derived code bloat are:
1) Overuse of object oriented (OOP) constructs – such as classes and inheritance – can lead to messy and confusing designs, often taking many more lines of code than an optimal solution.
2) Incorrect usage of design patterns – OOP developers will often attempt to "force" design patterns as solutions to problems that do not need them.
3) Overuse of OOP methods/functions/procedures – breaking an algorithm up into many methods is a way to allow developers to reuse these methods to solve other problems. However, this often adds code bloat and makes the code difficult, if not impossible, to read and debug and reduces algorithmic efficiency.
4) Declarative programming – implementing a declarative programming style in an imperative or OOP language often leads to code bloat.
5) Excessive loop unrolling – without justification through improved performance.
6) Excessive use of multiple conditional If statements – instead of, for instance, using a lookup table.
Some naïve implementations of the template system employed in C++ are examples of inadequacies in the compiler used to compile the language.
A naïve compiler implementing this feature can introduce versions of a method of a template class for every type it is used with. This in turns leads to compiled methods that may never be used, thus resulting in code bloat. More sophisticated compilers and linkers detect the superfluous copies and discard them, or avoid generating them at all, reducing the bloat. Thus template code can result in smaller binaries because a compiler is allowed to discard this kind of dead code.[1]
Some examples of native compiler derived bloat include:
1) Dead code – code which is executed but whose result is never used.
2) Redundant calculations – re-evaluating expressions that have already been calculated once. Such redundant calculations are often generated when implementing "bounds checking" code to prevent buffer overflow. Sophisticated compilers calculate such things exactly once, eliminating the following redundant calculations, using common subexpression elimination and loop-invariant code motion.
Examples
The following JavaScript algorithm has a large number of redundant variables, unnecessary logic and inefficient string concatenation.
--- Code: ---// Complex
function TK2getImageHTML(size, zoom, sensor, markers) {
var strFinalImage = "";
var strHTMLStart = '<img src="';
var strHTMLEnd = '" alt="The map"/>';
var strURL = "http://maps.google.com/maps/api/staticmap?center=";
var strSize = '&size='+ size;
var strZoom = '&zoom='+ zoom;
var strSensor = '&sensor='+ sensor;
strURL += markers[0].latitude;
strURL += ",";
strURL += markers[0].longitude;
strURL += strSize;
strURL += strZoom;
strURL += strSensor;
for (var i = 0; i < markers.length; i++) {
strURL += markers[i].addMarker();
}
strFinalImage = strHTMLStart + strURL + strHTMLEnd;
return strFinalImage;
};
--- End code ---
The same logic can be stated more efficiently as follows:
--- Code: ---// Simplified
TK2.getImageHTML = function(size, zoom, sensor, markers) {
var url = [ 'http://maps.google.com/maps/api/staticmap',
'?center=', markers[0].latitude, ',', markers[0].longitude,
'&size=', size,
'&zoom=', zoom,
'&sensor=', sensor ];
for (var i = 0; i < markers.length; i++) {
url.push(markers[i].addMarker());
}
return '<img src="' + url.join('') + '" alt="The map" />';
}
--- End code ---
Code density of different languages
The difference in code density between various computer languages is so great that often less memory is needed to hold both a program written in a "compact" language (such as a domain-specific programming language, Microsoft P-Code, or threaded code), plus an interpreter for that compact language (written in native code), than to hold that program written directly in native code.
Performance implications
In many cases, when two programs implement the same functionality, the larger program will also run slower than the smaller program. There are however a few cases where there is a space-time tradeoff -- in these cases, a larger program can run faster than a smaller one.
Reducing bloat
Some techniques for reducing code bloat include:
1) Refactoring commonly-used code sequence into a subroutine, and calling that subroutine from several locations, rather than copy and pasting the code at each of those locations.
2) Re-using subroutines that have already been written (perhaps with additional parameters), rather than re-writing them again from scratch as a new routine.
Minimalism
In computing, minimalism refers to the application of minimalist philosophies and principles in hardware and software design and usage.
History
In the 1950s, some mainframes had only 1,000 characters of memory. In the 1960s, mainframes had 4 to 64 Kilobytes of storage. In the late 1970s and early 1980s, with the earliest generations of personal computers, programmers had to work with the confines of relatively expensive and limited resources. 8 or 16 Kilobytes of RAM was common, 64K was considered a vast amount and was the Address space of the 8-bit CPUs of the day. Expansion beyond 64K would require bank switching. Storage capacities ranged from 88K floppy disks to (very expensive) 10 Megabyte hard drives. Personal computer memories have expanded by orders of magnitude over time, where system requirements remained the same for legacy software as it aged, making even the most elaborate, featureful programs of yesteryear seem minimalist in comparison with current software. Many of these programs are now considered abandonware. As the capabilities and system requirements of common desktop software and operating systems grew, many developers adopted minimalism as a philosophy and began choosing to limit their programs to a predefined size or scope.
In the early 21st century, changing applications for computing devices have brought minimalism to the forefront. It is no longer necessary to buy a high-end desktop personal computer merely to perform common computing tasks. Multiplication of devices such as smartphones, netbooks and plug computers have made minimalism an important design concern. Google's Chrome browser and Chrome OS are often cited as examples of minimalist design.
Usage
Developers may create user interfaces made to be as simple as possible by eliminating buttons and dialog boxes that may potentially confuse the user. Minimalism is sometimes used in its visual arts meaning, particularly in the industrial design of the hardware device or software theme. John Millar Carroll, in his book Minimalism Beyond the Nürnberg Funnel pointed out the use of minimalism resulting in little-or-no learning curve with the benefit of 'instant-use' devices such as video games, ATMs, and mall kiosks that do not require the user to read manuals. User Interface researchers have performed experiments suggesting that minimalism, as illustrated by the design principles of parsimony and transparency, bolsters efficiency and learnability. Minimalism is implicit in the Unix philosophy of "Do one thing and do it well."
Clippy:
Fat people just take up a lot of space! Much like software bloat.
fatman2021:
A hello world program written in QB64 produces a 645KB executable file. The same program written in x86 assembly is only 22 bytes in size. In other words QB64 produces executable that are 30,021 times bigger than the same program written in x86 assembly. There is no reason what so ever for a modern compiler to produce code that is so bloated.
fatman2021:
--- Quote from: Clippy on April 12, 2012, 01:07:44 PM ---Fat people just take up a lot of space! Much like software bloat.
--- End quote ---
Well for some reason you seam to not like it when I bring up software bloat. Now why could that be. Maybe it is because you are a lazy programmer.
LeChuck:
I suppose you wrote it since you didn't quote anyone.
Very nice article and I mostly agree, I spoke of this a long, long time ago. When I saw the installation size of Windows increasing by a factor of 5-10 with each new version and wondering, is there actually anything new in this version?!
Even more, they had the audacity to include messages like: Windows has become faster now. While the minimum requirements tripled.
Though I kinda stopped caring and I'm quite happy now with Windows 7 and the fact that it hasn't crashed on me yet. It is stable, it works, speed is okay on my system and it also works pretty well on my 200 euro netbook with quite low specs which I think is amazing.
Navigation
[0] Message Index
[#] Next page
Go to full version