Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

 

 

Pick an apple! 
 
View Extra Audio Details in Snow Leopard

In Snow Leopard, Option-clicking the Volume icon in the menu bar displays a list of sound input and output devices. Choose one to switch to it; it's much easier than using the Sound preference pane. Also, hold Shift and click the icon to set the system volume, which is separate from the general output volume.

Submitted by
Doug McLean

 
 

Software Acceleration Comments

Send Article to a Friend

We received a number of well thought-out comments abut Roy McDonald's article on software acceleration in TidBITS #186. Although we don't have room for all of them, here are a few notes:

Larry Rosenstein <lsr@taligent.com> and several others disagreed with Roy's statement that "OOP is an obvious formula for inefficient code." Larry felt that this is a myth, pointing at the fact that the System 7 Finder is a new program that hasn't been optimized, in contrast to the System 6 Finder, which had gone through several iterations that would help speed it up. Larry also noted that many commercial Macintosh applications have been written with object oriented techniques, including popular programs like Photoshop (and incidentally, Akif Eyler's Easy View), and that it's impossible to tell which were written with object oriented techniques based solely on performance.

Jeffrey A. Porten <jporten@sas.upenn.edu> wonders if hardware advances are not often the reason for software inefficiencies. He remembered discussions circa 1985, when programmers would code their software for the Apple //e and then spend months picking over their code paring out five bytes of code here and ten bytes of code there, simply because they had to - they were programming for machines with only 64K of RAM, and disks only stored 143K of information. Today's higher expectations require larger programs, but Jeffrey can't believe that the 1985 philosophy produced his 8 MB word processing folder or his 3 MB System Folder.

Tom Lane <tgl@netcom.com> passed on an old item of computer science wisdom about there being multiple levels of system design, with independent speedups possible at each level. For example, you can describe a system independently at the levels of:

  • software architecture (module structure)
  • high-level algorithms (e.g. Roy's sorting example)
  • low-level coding practices
  • compilation (translation to machine code)
  • hardware architecture (buses, caches, etc.)
  • hardware realization (circuitry)

If we imagine that sufficient work can produce a speed increase of 10 times at each of these levels, then we see how to solve our problem one million times faster.

Michael Crawford <crawford@na47sun05.cern.ch>, author of Working Watermarker, the Word Services Apple Event Suite, Webster's Electronic Dictionary and Thesaurus for the Macintosh, and others, writes:

I greatly enjoyed Roy McDonald's article on software speed that appeared in TidBITS #186. I've been contemplating the same issues for the last several years and have some comments. I think Roy's ideas on the lack of good algorithms in commercial software can be summarized as follows:

  1. Productive software engineers often don't know computer science.

  2. Computer scientists can't ship a commercial product.

  3. Many software engineers can't program either.

It has been my experience everywhere I have worked that few, if any, of the production engineers follow any of the academic literature on algorithm or operating system design. For this reason, good ideas from academia either never show up on the market, or only show up after many years when a developer comes up with it independently, claiming it as an innovation.

Few commercial publishers really use "computer science" in their products. Connectix is a notable exception to this sad fact.

There is another issue that Roy didn't address - software quality. I think that the crux of the speed problem lies in quality. The fastest software is useless if it crashes frequently.

I've spent most of my career on the Mac, on the PC, and on Unix fixing someone else's broken code. I have been astonished at the awful quality of the software rats' nests I've debugged. Commercial developers often avoid tricky algorithms, not just to get to market quickly, but to get to market at all. With the poorly structured code often found in commercial products, attempting an n^2 algorithm to nlog(n) would often result in failure because the code would never work at all.

I believe this occurs either because programmers have no formal training - I got my start in programming as an astronomy student - or because the traditional teaching of computer programming over-emphasizes the teaching of algorithms by coding simple homework problems that take a few days to a week to do.

A software engineering curriculum, as opposed to a computer science curriculum, would teach project management, team programming, and version control, and engage an entire class of students in the coding of a single program that would take from one semester to one year to complete. [Sounds like a great way to produce incredibly useful software for the community as well. -Adam]

Much of the industry's problems in software quality could be fixed, not by doing object-oriented programming, but by learning proper structured programming, and having the discipline to program in a structured manner. OOP has gained in popularity, not so much because it is inherently superior, but because it is impossible to make a program work unless one has the discipline to design the class structure of the program in an intelligent manner to begin with.

I've read much spaghetti code written by (pardon my tirade) imbeciles who claimed they wrote structured code. I have three tests for good structure that work well in practice and have helped me repair many a broken program:

  1. Well-structured code can be easily modified for a purpose different than that for which it was originally intended.

  2. Pieces of well-structured code can be understood fairly well without understanding the program as a whole.

  3. Modules of code that perform general utility functions can be easily removed from a project and incorporated into a completely different project without changing header files, or bringing along a bunch of other utility functions.

Object oriented code usually does not pass the third test, whereas structured code often does. It is my experience that any code which can satisfy the above criteria is easily fixed when a bug is found, and can be easily modified to use faster algorithms.

 

READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <http://tidbits.com/member_benefits.html>
Special thanks to David Weeks, Stephen Reeves, Donald Reid, and
Douglas Chong for their generous support!