tom@wcc.oz (Tom Evans) (12/10/90)
Now that I have your attention, the full reference is: Lies, Damn Lies and Statistics. And Benchmarks. :-) Sorry for the length of this - I hope it clears a few things up. > Tom Benedict@polari.UUCP writes: >> The upgrade situation is a real thorn for system administrators >> who would like to stick with HC1.2x for performance reasons yet >> must run HC2 on some machines. > > "Hmm, abysmal performance or worse-than-abysmal performance, > hmm...I'll pick abysmal performance..." So HC2 is slower then HC1? I used to think so too, but it ain't that simple. On the weekend I noticed that HC2.0 was a lot slower than HC1.2.5, so I started measuring things. MonoFinder on a IIcx and System 6.0.5: Test Description 1.2.5 2.0 1.2.5/2.0 ----------------------------------------------------------------------- 1 repeat 50000 - null loop (ticks) 759 207 3.66 2 repeat 500 send message (ticks) 256 85 3.01 3 Write into scrolling field (ticks) 704 690 1.02 4 Collect data from cards to field (sec) 22.14 19.23 1.15 HC2 is lots faster. The time taken in the third test was probably 90% toolbox calls (nothing HC can do about this). Lots of toolbox calls in 4 as well. Note (4) is a "real world" test - part of a stack I wrote. MonoFinder on a IIcx and System 6.0.5 with ** 6 DA's on screen: Test Description 1.2.5 2.0 1.2.5/2.0 ----------------------------------------------------------------------- 1 repeat 50000 - null loop (ticks) 754 209 3.61 2 repeat 500 send message (ticks) 280 127 2.20 3 Write into scrolling field (ticks) 711 1043 0.68 4 (didn't do this test) With DA's competing for the processor, HC1 lost 0%, 9% and 1%. HC2 lost 1%, 34% and _34%_!! Looking at this I can also tell WHEN HC2 gives time away - not while looping in a single script, but when passing messages. All you speed-scripters take note - ultra-bad style (monolithic code - ugh!) leads to far more speed (again). Torture time. MultiFinder, Word, NCSA Telnet, HC1 AND HC2 and 5 DA's: Test Description 1.2.5 2.0 1.2.5/2.0 ----------------------------------------------------------------------- 1 repeat 50000 - null loop (ticks) 785 222 3.58 2 repeat 500 send message (ticks) 269 182 1.47 3 Write into scrolling field (ticks) 726 1364 0.53 4 Collect data from cards to field (sec) 23.17 31.96 0.72 Who'd be so bad as to load a machine like this? We all do, don't we? Simply stated, HC 2 is heaps faster on simple benchmarks, but slower in "real life". This is because HC2 obeys Apple's specifications for a "well behaved" application. To get it fast you have to break all the rules, or get rid of the competition. If you want HC2 running fast on your Mac - get rid of all that clutter on your desktop that's wasting cycles - kill the DA's and applications you're not running. On certain operations you'll double the speed, and exceed what HC1.2 ran at. ======================== Tom Evans tom@wcc.oz.au ** ADD ".au" MANUALLY (don't trust "reply") ** Webster Computer Corp P/L, 1270 Ferntree Gully Rd Scoresby, Melbourne 3179 Victoria, Australia 61-3-764-1100 FAX ...764-1179
smelly@polari.UUCP (Tom Benedict) (12/14/90)
The HC2.0 benchmarks posted in msg 3214 by Tom Evans were bvery interesting. They spoi sp support what I've been thinking all along, which is that HC2.0 has trouble (well, not really trouble, but it does slow down) with figuring out what objecxts are on the screen. I suppose this has to do with the new supposrt for windows and the overhead needed for that. Most of the stacks I create have to run on SE's and the slower response to clicking on an object which I've experienced under 2.0 couple with the initial compile times cause less than smooth operation of my stacks. I've gone through them to optimize for HC2, performing illusions and tricks all along the way, but the interface is still slower! Once the script is running it's great!! Unfortunately even compiled scripts in RAM seem to disappear after a while. I warm up long scripts on openStack but even in a 3MEG partition they eventual ly get pushed out of the stack. Mr experience (I mean MY experience) in the compiler is that an 8000 byte script takes about 4 secs to compile. Even on a MacII thats rather slow. I wish there was a way to turn off the compiler when I don't want it. () While I'm on the line...I reported the 'div by sero' bug to Claris and they were able to reproduce it on a number of machines. BIG ID-4 bomb!! Hope they have a fix for it soon. In the meantime..DON't DIV by zero!! (only bombs in 20v2, not 20) Tom Benedict smelly@polari.uucp