Apr 93 Tips, Tidbits
|Column Tag:||Tips & Tidbits
Related Info: Script Manager
Tips & Tidbits
By Neil Ticktin, Editor-in-Chief
This column is your opportunity to spread the word about little bits of information that you find out about. These tidbits can be programming related or they can be user tips that are particularly useful to programmers.
MacTech Magazine will pay $25 for every tip used, and $50 for the Tip of the Month. Or you can take your award in orders or subscriptions.
To submit a tip, send in a letter to the magazine. E-mail is our preferred method, but feel free to send something via the US Mail. See page two for all addresses. If you do send snail mail, enclose a printed copy and a disk copy of the letter so that it does not have to be retyped.
Tip of the month
Here is a simple routine that returns a Boolean indicating whether the monitor is currently set at black & white or color.
/* 1 */
Boolean IsColorOn( void )
hGDevice = GetMainDevice();
theMode = (**hGDevice).gdMode;
theMode &= 0x0000000F;
if( theMode != 0 ) return( true );
else return( false );
I figured out how to write this piece of code after struggling with the concept for many months. Its not a very complex routine, but I searched through every source I had available and never found anything that explained how to do it. I hope this will help others having the same problem.
- Marc White, Corinth, Mississippi
Script Manager Pitfall
If you plan to work with non-Roman script (such as Kanji, Arabic, Hebrew, etc ), there is a subtle - but important - point that Inside Macintosh will not tell you.
Script Manager functions can return wrong answers if the appropriate font is not set in the current GrafPort.
For example, there is a Script Manager function called CharByte which tells you if a given character is part of a two-byte script (or not). After reading the description of CharByte in Inside Macintosh, you will conclude it will know the right answer simply by looking at a piece of text. Wrong!
Unless the current font is a Kanji font, CharByte has no way of knowing that a given character is part of a double-byte Kanji character or whether it is a single-byte Roman character.
The reason is all 256 byte values are valid for all Roman fonts. If the current font is, say, Geneva, CharByte will think that 1/2 of a Kanji byte is really a single Roman character.
This is neither clear in Inside Macintosh Vol 5 nor the World Script section in Vol 6, but it is a fairly major point!
- Gar, DataPak Software
Apples Lame Disk Cache
After seeing significant I/O performance problems with large disk caches (set via the Memory control panel) I decided to run some benchmarks. I wrote a little application that would write a 400K file to a hard disk in 8K sector aligned chunks with various disk cache sizes and return to me the number of ticks that it took. Here are the results:
disk cache size 8K at a time
32K 50 ticks
64K 50 ticks
96K 51 ticks
128K 50 ticks
192K 50 ticks
256K 50 ticks
384K 691 ticks
512K 681 ticks
1024K 681 ticks
7680K 678 ticks
It appears that the Apples disk cache scheme hits a wall at 384K (in this test, anyway). I linked DTS with these results and got an interesting reply. It turns out that their disk cache scheme is optimized for very small reads and writes - like an application reading one byte at a time from a file without doing it's own buffering. I guess this was a problem back when most people used floppies and small hard drives. But modern apps usually do their own file buffering anyway (read a big piece into a buffer and then take it out of the buffer one byte at a time), so the Apple disk cache scheme becomes more of a hinderance than a help.
Not all reads and writes are cached by the Apple scheme. The formula it uses to decide if any given read or write should be cached is:
/* 2 */
numCacheBlocks = user-defined cache size DIV 512;
maxCachedReadWrite = (numCacheBlocks - 1) * 16;
So, with a cache size of 256K you get:
numCacheBlocks = 512
maxCachedReadWrite = 8176
That means that any read/write larger than 8176 bytes or larger will not be cached. So in my test app, nothing was being cached until the cache was 384K or larger, at which time my 8K writes were being cached (and I got a 13x performance slow-down).
There is hope, though. Page 2-95 of the new Inside Macintosh File Manager documents the "no cache" bit of ioPosMode. You can set bit 5 of ioPosMode to prevent your reads and writes from being cached. I strongly recommend you do this except in those few cases where you know you're going to need the data again right away or where you're not doing your own intelligent sector-aligned buffering. When I set this bit in my test app, my times for writing 400K with very large caches were the same as those for writing 400K with very small caches.
That's great for your code but what about other code that you can't control and that doesn't take advantage of bit 5 of ioPosMode? The only real defense is to reduce your disk cache to the minimum (32K) at which time only very small reads and writes will be cached (1008 bytes or less). But in my own tests with compiling large projects under MPW and Think C I have found that a disk cache size of 128K gives the fastest build times. You should do your own timings based on what type of I/O operations you do most.
- Mike Scanlin
MacTech Regular Contributor
Useless Trivia or a tip?
This is perhaps more fit for Useless Trivia than is is for Tips and Tidbits, but no matter, here it is:
Nearly every piece of C code that I ever see (even in MacTech Magazine) uses parentheses around all return statements. People always seem to write:
Even the examples in K&R itself use parentheses around the return statments. But look at the actual syntax reference in K&R: if, while, for, and switch all require parens, but return does not. For years, using many compilers, on many machines, I've been writing:
It may look odd, but try it - it does work!
- Ken Gladstone
MacTech Technical Editor