chas@gtss.UUCP (Charles Cleveland) (05/22/87)
Now that Kim has straightened out my SetFont problems, I decided to test
BlitzFonts out. This was with a few utilities like Popcli & PIPE: installed.
I type'd the unstripped version of the C include files for intuition, namely
<intuition/intuition.h> which makes up 54944 bytes, both with Topaz and with
and without BlitzFonts (I turned it on and off with BlitzFonts & BlitzFonts -r)
and also with Pearl installed instead of Topaz with SetFont Pearl (the
Haynie 2.0 version recently posted by Kim). I ran a little script from ram:
date
type df1:intuition/intuition.h (or ram:intuition.h)
date
for timings. As indicated above I either copied from a floppy or ram:, both
results are indicated below. Allow me to say that Blitzfont *looked* much
faster.
In the results below, B means BlitzFonts was on, NB means it was off, T means
the (global) font was Topaz and P means the (global) font was Pearl. In the
copies from disk the times were (I did not use AddBuffers)
m:sec m:sec
NB T 1:38 B T 1:26
NB P 1:37 B P 1:39
In the copies from ram the times were
m:sec m:sec
NB T 1:34 B T 1:21
NB P 1:32 B P 1:34
I have seen considerable variation in these times. Greater than the differences
with and without BlitzFonts. I've gotten Topaz times like 1:14 without BF and
1:02 with it (the system was loaded differently). My measurements seem to show
than BlitzFonts with non-Topaz fonts works about as well as it does with Topaz,
and that no BlitzFonts works about as well too. Of course since 'type' is
part of who-know-what these results may all be the fault of AmigaDouche.
Perhaps other testers can give times for non-AmigaDOS (but commonly available)
tests.
This BlitzFonts was the one posted by Kim recently.
Please do not confuse these times with those gotten by using Blitz, which
is unquestionably faster but which does not accelerate other programs text
output.
--
Charles Cleveland EDU: chas@ss.physics.gatech.edu
Georgia Tech School of Physics UUCP: ...!{akgua,allegra,amd,hplabs,ihnp4,
Atlanta, GA 30332 masscomp,ut-ngp,rlgvax,sb1,uf-cgrl,
unmvax,ut-sally}!gatech!gtss!chasdillon@CORY.BERKELEY.EDU (Matt Dillon) (05/22/87)
> m:sec m:sec >NB T 1:38 B T 1:26 >NB P 1:37 B P 1:39 You don't see much of a speed increase when scrolling. The speed comes when writing text into a window without scrolling (e.g. DME updating a screen, bringing up large menus, etc...). -Matt
chas@gtss.UUCP (Charles Cleveland) (05/24/87)
Thanks to Matt for pointing out how scrolling slows down BlitzFonts. Here's
some timings with and without scrolling and using both Type and Copy. Leaves
me wondering what Type is doing extra.
I ran all these tests at the same time with my system load unchanging. The
times were very consistent. Let me say to save space below that
the PD Blitzfonts produced times with Pearl that were indistinguishable
from those of the usual Text routines with Pearl or Topaz.
For the purposes of producing something that would take long enough to
get on the screen for a decent timing and still not scroll I made a file
with the following repeated 50 times
<ESC>[H<ESC>[J
20 lines of 72 a's
That is 50 pages of a's with the page cleared at the start of each page.
A total of 73350 bytes counting newlines.
Using 'Type' took 1:09 without BlitzFonts and :54 with it.
Using 'Copy file to *' took :32 without BlitzFonts and :17 with it.
When I reinstated scrolling by eliminating all the <ESC> lines and adding
enough 'a' lines to bring the byte count back up to 73350 I got the
following results
Using 'Type' took 1:32 without BlitzFonts and 1:17 with it.
Using 'Copy file to *' took :56 without BlitzFonts and :41 with it.
Now I would say that the last improvement is adequate, being a 37%
percent increase so even with scrolling Copy sees a benefit from BlitzFonts.
And the result for Copy with no scrolling is a 88% increase -- quite
nice. But with NO SCROLLING the best Type can do is a 28% increase.
Of course Type is much smaller than copy but I always figured that was
because it didn't have to interpret file name patterns. Is this smallness
my reward? Or is Type deliberately SLOWED DOWN because its authors figured
people would be trying to read the text as it came by ? (Not a bad reason.)
And what out there enjoys the increases of 400% I have seen quoted?
--
Charles Cleveland EDU: chas@ss.physics.gatech.edu
Georgia Tech School of Physics UUCP: ...!{akgua,allegra,amd,hplabs,ihnp4,
Atlanta, GA 30332 masscomp,ut-ngp,rlgvax,sb1,uf-cgrl,
unmvax,ut-sally}!gatech!gtss!chasdillon@CORY.BERKELEY.EDU (Matt Dillon) (05/24/87)
>And what out there enjoys the increases of 400% I have seen quoted?
I think this was already mentioned, but there seem to be two
different 'blitz' programs.. 'Blitz', and 'BlitzFonts'.
Blitz is hardwired for the Topaz 8x8 font and gives at least 400%
increase in speed for non-scrolling applications which use text a lot
(for example, DME redrawing a window becomes a bare flicker).
Blitzfonts on the other hand works with non-proportional fonts
other than Topaz 8 (not sure if they still must be 8x8, but I don't think so),
and gives a 10 to 80% improvement in speed.
-Mattandy@cbmvax.cbm.UUCP (Andy Finkel) (05/26/87)
<paranoia strikes deep...> In article <120@gtss.UUCP> chas@gtss.UUCP (Charles Cleveland) writes: >Thanks to Matt for pointing out how scrolling slows down BlitzFonts. Here's >some timings with and without scrolling and using both Type and Copy. Leaves >me wondering what Type is doing extra. > Nope, nothing complicated. Its just that COPY uses a big buffer (100K) and TYPE uses a small buffer (a character). >Of course Type is much smaller than copy but I always figured that was >because it didn't have to interpret file name patterns. Is this smallness >my reward? Or is Type deliberately SLOWED DOWN because its authors figured >people would be trying to read the text as it came by ? (Not a bad reason.) That's one reason it didn't need a large buffer...vast speed is inconsistent with its basic mission in life. -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga "An end is always a new beginning." - Captain Cloud Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
scotty@l5comp.UUCP (Scott Turner) (05/27/87)
In article <8705240640.AA25544@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I think this was already mentioned, but there seem to be two >different 'blitz' programs.. 'Blitz', and 'BlitzFonts'. There are two different blitz programs Matt. But they each do ENTIRELY different things. Blitz is a VERY nice text file scanning program. If it hasn't been posted to the net I'm real tempted to. :) I use this program all the time. You can grab it's screen with the mouse and yank it up and down real quick and Blitz keeps right up. Blitz can also: Print the file, Strip/convert CR's, change it's view of how big a tab is, set a book mark, search for a string. This last function is real fun to watch because Hayes makes the program SCROLL through all the text till it finds the string. And bpy can this program scroll! A must see. The other feature I like is that he used Mac style file requesters. You can double click the filename in the requester and it will press the load button for ya. BlitzFonts is the program Hayes wrote to speed up text output for the rest of us. It comes in two flavors, the one that can be given away: hardwired for Topaz, and the one you get when you send in your bux: which can handle fonts other than Topaz. BTW, Blitz also comes in two flavors, the giveaway version can't print files. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)