A Discussion on Ticks and Patches
(Addition comments are at the end of the original article)
The beauty of ResEdit, and many of the edits here on ResExcellence, is that they add new features to your computer without the overhead of additional extensions or control panels.
Increased conflicts are not the only reason to be concerned about the number of icons that crawl across your screen at startup. Each of these little bundles of code exacts the price of a few lost processor cycles. But how can you tell who the biggest culprits are?
Start by downloading the $8 shareware program, SpeedTester 2.2. This utility counts how many milliseconds it takes to execute 10,000 calls to the Macintosh toolbox routine, GetNextEvent(). The more processor cycles that are used by extensions and control panels, the longer the 10,000 calls will take.
If you restart your computer with extensions off (holding the shift key during boot), you can then run Speed Tester and arrive at a base number to compare your extensions against.
After three GetNextEvent() tests, my Powerbook 3400 averages 2700ms for the 10,000 calls.
Next, I loaded Conflict Catcher 8, disabled all extensions, and ran the test again. It was a surprise to see the number had jumped to 2800ms. Why? It seems that the Conflict Catcher extension installs nine system patches of its own!
From Conflict Catcher's Report:
Trap System Trap Name Startup File Name
-----------------------------------------
A8EC CopyBits
006D1810 PowerPC PPC&68K Conflict Catcher
A817 CopyMask
006D5CB0 PowerPC PPC&68K Conflict Catcher
AA0E FillCRect
006007A0 PowerPC PPC&68K Conflict Catcher
AA12 FillCRgn
005FF880 PowerPC PPC&68K Conflict Catcher
A8A5 FillRect
005F5B20 PowerPC PPC&68K Conflict Catcher
A8D6 FillRgn
005F5860 PowerPC PPC&68K Conflict Catcher
A912 InitWindows
006D0BC0 PowerPC PPC&68K Conflict Catcher
AA1F PlotCIcon
006D17B0 680x0 PPC&68K Conflict Catcher
A8DE SetRectRgn
006D1760 PowerPC PPC&68K Conflict Catcher
The chart above describes the System trap, whether the trap is a PPC or 68k routine, and then whether the code inserted into the routine is PPC or 68k code. This last item is particularly important. Imagine a PPC native System trap that gets patched with a 68k piece of code. In order for the routine to execute, the operating system's emulator steps in to translate the 68k code to the PPC equivalent. This takes even more time. To its credit, all of the patches in Conflict Catcher are written in both PPC and 68k.
Next, let's add Speed Doubler to the mix.
Using Conflict Catcher, I activated the Speed Doubler Extension and Control panel, restarted the computer, and ran Speed Tester again. The new score dropped to 2400ms. I'm attributing this to Speed Doubler's faster 68k emulation.
There was one other item I wanted to add to what was going to become my new base set of test extensions - RAM Doubler 8. It was a pleasant surprise to see that RAM Doubler's impact on the System was minor, a mere 100ms of additional delay.
If fact, for the rest of the tests, most extensions added only a couple of dozen milliseconds of delay each. There were a couple of notable exceptions.
The addition of Quickeys slowed the calls to GetNextEvent() to 7100ms; that was more than three times my base test set!
Another culprit was SpellCatcher, which jumped the test score to 4900ms.
What factors were at work to make these to programs have a disproportionate effect on the system?
It all comes down to the patched System routines. These programs have inserted many 68k chunks of code into PPC routines. The result is lost time due to emulation.
With my current set of macros, Quickeys installs 41 different system patches - 17 of them are 68k patches on PPC code. With SpellCatcher, the end result is the same - 10 total patches, 3 of which patch PPC routines with 68k code.
Can you really feel the impact of these patches in your applications? Yes. The addition of Quickeys decreases my window scrolling by 9% over scrolling with extensions off. When I load my normal extension set, which clocks in at 7000ms and doesn't include Quickeys, but does load Spell Catcher, Finder scrolling increases by 35%!
After every new install that involves an extension or control panel, I run Speed Tester. If I notice a jump in the time, I weigh the benefit of that program and decide whether or not to always leave it on, or switch it as needed with Conflict Catcher. This diligence allows me to run a current set of 28 extensions that patch the system 163 times. Yet I feel my computer still moves at a spritely pace, and is very stable.
If you have any comments or questions, please send them to me for addition to this discussion.
10-5-98
From: Larry Rosenstein
Subject: A Discussion on Ticks and Patches
>This utility counts how many milliseconds it takes to execute 10,000 calls >to the Macintosh toolbox routine, GetNextEvent().
This only detects very localized performance issues. GetNextEvent() doesn't call much of the Toolbox. Also, the speed of GetNextEvent() isn't very important, since events are usually generated that fast. (How fast can you accurately type?)
You shouldn't evaluate whether to use an extension based on how they affect calls to GetNextEvent(). You should test out things that you commonly do in the Finder or applications.
>It was a surprise to see the number had jumped to 2800ms. >Why? It seems that the Conflict Catcher extension >installs nine system patches of its own!
Going from 2700ms to 2800ms isn't much of a jump (3.7%). None of the patches listed in the report are onces that GetNextEvent would call, so it's hard to see how Conflict Catcher could have caused this difference.
>trap that gets patched with a 68k piece of code. In order for the >routine to execute, the operating system's emulator >steps in to translate the 68k code to the PPC equivalent. >This takes even more time. To its credit, all of the patches in >Conflict Catcher are written in both PPC and 68k.
Whether a mixed mode switch is important depends on what trap is called. If the trap itself takes several milliseconds, adding a few microseconds because of a mixed mode switch isn't significant.
Patching with both PPC and 68K code isn't completely free, however. Patches with both 68K and PPC code take up more space in memory, and if you are using VM patches normally cannot be paged out.
>8. It was a pleasant surprise to see that RAM Doubler's >impact on the System was minor, a mere 100ms of additional delay.
Above, you said that that 100ms was a "jump".
ResExcellence comments: It's not the amount of the change, but that there was any change at all is what I surprised me.
>The addition of <http://www.cesoft.com> Quickeys slowed the calls to >GetNextEvent() to 7100ms; that was more than three times my base test set!
Not surprising. QuicKeys generates has to generate events, so it probably patches a lot of the event system.
>It all comes down to the patched System routines. >These programs have inserted many 68k chunks of code >into PPC routines. The result is lost time due to emulation.
But the event system is mostly 68K code any way; the issue isn't the lack of PPC native patches
I believe the issue is just that things like QuicKeys install patches to GetNextEvent and other things in the event system that take time.
>different system patches - 17 of them are 68k patches on >PPC code. With SpellCatcher, the end result is the same
How many of these are executed by GetNextEvent?
>your applications? Yes. The addition of Quickeys >decreases my window scrolling by 9% over scrolling with extensions off.
This is a better test of the impact of extensions.
ResExcellence comments: While I understand the logic of your argument, if patches outside of the event loop don't have an effect on speed, why do I notice a decrease in GetNextEvent() with almost every extension that installs patches?
From: Jon Mircea
Subject: re: patches and performance and ticks
Hiya Michael,
Just read your quite fine article on extensions and their impact on your system. I'd like to add a note to your notes though... ;-)
With some system extensions and patches, you won't actually see much, if any result on just the get next event state. For example, Kaleidoscope will not show much of a change for the get next event state, it's done all of it's thinking the second you let go of the menu bar to activate the get next event count.
Kaleidescope's slowdown is seen in every screen redraw or new window opening on my system, though, and overall, though it would hardly rate on your little test, due to it just not being active during that test. Nothing's causing a screen redraw.
Now, this is just an example, but there are more programs that can fall into this category, including things like PowerWindows, SmoothType, etc. These things calculate when they draw em the first time, and during screen redraws. Not during wait states.
Though your method is indeed excellent for detecting mass slowdown from system-wide active things, such as RamDoubler, Norton DiskLight, OneClick, etc (as they're either always working away, or always checking something for activity - oneclick for key combinations, etc, and for it's recording system, which even when not in use, is "active", DiskLight checking to see if any disks are moving, and if they are, woohoo... impact on system time city... drawing, rechecking, drawing... amazing it has time left to do any disk access...), it is fairly ineffective at detecting other kinds of slowdown and increases.
Also - another note as to why patched traps are almost always slower - memory fragmentation. The code has to jump more ram pages. Each ram page jump takes around 2 processor cycles. When the code is pristine, and unpatched, it's all closer to early ram and closer to each other, thus it flows so much better. Of course, this is for non-vm... I think they've managed to get it down to about 4 cycles on average, but can get as fast as around 2.5 cycles.
ResExcellence comments: I had never heard of the memory fragmentation aspect of it before. Very interesting. It's amazing we're gotten to the level of discussion time in millionths of a second!
From: James Conner
To: <coyle@ResExcellence.com>
Your fine article on evaluating the speed hit for extensions persuaded me to download SpeedTester and run some tests on my machine. A couple of quick notes:
(1) The Get Next Event test results show considerable variation. With extensions off, running the test at 5X yielded these times on my Umax C-500 (180mhz 603e, 112 megs RAM): 3221, 3477, 3588, 3262. I suspect users would be well advised to run the test at least five times and take an average.
(2) With extensions on, the same test yielded 12,480. You can bet I'll be running tests to isolate the cause of this slowdown.
Best regards,
James Conner
Date: Wed, 30 Sep 1998 06:51:48 -0400
Subject: Speed Testing
From: Stephen Giles
I use a freeware application called "Response and Jerkiness" to test for system sluggishness. It does 2000 GetNextEvents() and then rates your system. I have found the following to have a large impact on system ratings:
Kensington Startup 5.0.4 (I can't really live without it)
QuicKeys 3.0.1 (I've stopped using it)
Sounds4Fun 1.0 (I actually run Sounds4Fun 1.0b6 because it has negligible impact)
Date: Wed, 30 Sep 1998 10:52:10 -0700
Subject: SpeedTester Results
From: Larry Kelly
The significant performance hit I found was the Viewer Engine extension and True Finder Integration Control Panels that are part of Stuffit Deluxe. My startup with all files disabled with Conflict Catcher gave a GetNextEvent() time of 1448 milliseconds. When the two files above are added, the time extends to 3012 ms. Machine is a PowerTowerPro 225.
Date: Wed, 30 Sep 1998 09:30:56 -0400
To: coyle@ResExcellence.com
From: Rod Paine
Well, now you've done it! You let the cat out of the bag with respect to telling everybody how to "tune" their Mac... now we won't be able to charge big bucks to do it for them. ;-)
I am kidding, of course, but good to see you draw attention to Brian's Speed Tester, which we've used for several years to identify things that can sap Mac horsepower. Prior to Brian's effort, we used CheckTicks, which Brian based Speed Tester on, of course, but with significant improvements.
Interesting that you mention QuicKEYS, as it is also very popular with our Mac business user and graphic design clients. One of the things Speed Tester users can also do is to try earlier versions of their add-on's, such as QuicKEYS to see if they run faster. For example, QuicKEYS 3.0 with Speed Doubler is considerably less "Ticks Intensive" than v3.5 in many machine environments. The same is true for some other earlier versions of third-party Extensions.
Using Speed Tester to identify and test different Extension/Control Panel configurations is a time consuming process, but the results can be well worth the effort, in terms of improved performance with many Mac configurations. And, unlike huge applications such as MacBench, which takes many minutes to obtain a result, presenting a meaningless number, Speed Tester is quick and shows effects that MacBench doesn't.
I don't think Brian received much interest in Speed Tester and that's a real shame, because it is a very worthwhile tool. Perhaps your recent comments about it will bring the attention it deserves.
Along the same lines, Roger Bates Time Drive which was written many years ago for La Cie, is also a very good tool to examine disk drive and even network mounted volumes performance, quickly. We use it extensively during RAID setup to assist with mode page tuning. The combination of Speed Tester and Time Drive has allowed us to deliver Mac configurations that are well above identical Mac models in terms of performance, as any of our client's would be happy to acknowledge.
Again, thanks for bringing Speed Tester to the attention of others. They will thank you. Perhaps renewed interest might get Brian and Roger to return to their earlier versions and bring them up to date. I know many of us would certainly appreciate that and I would hope all would be happy to pay for upgrades, for such great little applications.
Regards,
Rod Paine
Date: Thu, 01 Oct 1998 12:46:19 -0500
From: Matthew Ruben
To: coyle@ResExcellence.com
Subject: Extensions and Speed Tester
Hi there,
Loved your feature on extensions and speed effects. I downloaded speedtester and ran the GetNextEvent on my 7300 (with Powerlogix G3 running at 303/121). I was surprised at the results.
I run with quite a number of extensions -- the standard OS8.1 ones including Open Transport, Quicktime 3 and Quickdraw 3D (but not contextual menus, Maclink/Easy Open and Color Picker), as well as Conflict Catcher, KeyQuencer, TechTool protection, drivers for my Ultimate Rez and G3 cards, Microsoft OLE and ATM.
My "baseline" GetNextEvent Speed Test, with all extensions off by holding down the shift key during startup, averaged 800-900 milliseconds. With my full complement of extensions, it shot up to around 6900ms !!!
After running some tests, I discovered that only two extensions were the real culprits. Adobe Type Reunion (the old v1.2) adds 500-600 ms, and Watcher--Keyquencer maker Binary software's hilarious freeware extension -- adds about 5200 ms to the Speed Test!
So it's with much sadness that I'm retiring this adorable extension from my startup lineup. And it is will somewhat less sadness that I've decided to live with a non-sorted font menu in my copy of MSWord 5.1. But my Mac is sure to be faster for it.
Hope you find this info useful.
Again, thanks for such a great site.
Matt Ruben
Philadelphia |
