stevem@hpvcfs1.HP.COM (Steve Miller) (11/29/89)
I had the chance to play with a NeXT machine a little. It supposably had a 330 Meg disk installed so I assumed it wouldn't have the throughput problems that some people have complained about. However, when running the word processor (WriteNow ?) I noticed that it took a very long time to load and that scrolling and moving throught the document was very slow. This surprised me considering the amount of horsepower the NeXT machine is supposed to have. When going to the bottom of the ducument, it took about 5-10 seconds to redraw the screen. Is word processing really this slow on the NeXT, or is WriteNow just a slow word processor? I'm used to a Mac II, and even when running Adode Type Manager (their screen font scaling technology), text editing and program launching is quite fast. Does anyone have a good idea of why the NeXT was so slow? Steven Miller Vancouver Division Hewlett Packard
chari@nueces.cactus.org (Chris Whatley) (11/29/89)
stevem@hpvcfs1.HP.COM (Steve Miller) writes: >Is word processing really this slow on the NeXT, or is WriteNow just a slow >word processor? I'm used to a Mac II, and even when running Adode Type >Manager (their screen font scaling technology), text editing and program >launching is quite fast. Does anyone have a good idea of why the NeXT was >so slow? It is definitely WriteNow that is the problem. It is a VERY slow and clunky program. They have cleaned it up alot but it is still not a "hot" item in my opinion. I really hope T-Maker changes this in the next release. Right now I'd rather use Edit in RTF mode to create the document and then open that in WriteNow and paste in whatever pictures I need. At least then I have some decent editing commands (at least ones which are consistent with the emacs bindings prevalent in other apps). Chris -- Chris Whatley Work: chari@pelican.ma.utexas.edu (NeXT Mail) (512/471-7711 ext 123) Play: chari@nueces.cactus.org (NeXT Mail) (512/499-0475) Also: chari@emx.utexas.edu
daveh@cbmvax.UUCP (Dave Haynie) (11/29/89)
in article <770002@hpvcfs1.HP.COM>, stevem@hpvcfs1.HP.COM (Steve Miller) says: > Is word processing really this slow on the NeXT, or is WriteNow just a slow > word processor? I'm used to a Mac II, and even when running Adode Type > Manager (their screen font scaling technology), text editing and program > launching is quite fast. Does anyone have a good idea of why the NeXT was > so slow? My guess would be that it's mainly either WriteNow, Display PostScript, or the combination that's the slowdown. Don't know what kind of screen you're driving on the Mac II (the size is certainly a factor), but I'm regularly using a DTP program with it's own scaled fonts (Gold Disk's Professional Page, which uses Agfa/Compugraphic outline fonts) on an Amiga 2500/30 (25MHz 68030 system, a little slower on memory reads than the NeXT) with a Moniterm Viking monitor (1000x800 or 1000x1000, with 2 bitplanes), and everything is really nice and fast. The NeXT hardware should be capable of the same speeds, so it's gotta be something obvious in the software. > Steven Miller > Vancouver Division > Hewlett Packard -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
dennisg@kgw2.UUCP (Dennis Glatting) (11/30/89)
In article <770002@hpvcfs1.HP.COM>, stevem@hpvcfs1.HP.COM (Steve Miller) writes: > Is word processing really this slow on the NeXT, or is WriteNow just a slow > word processor? I'm used to a Mac II, and even when running Adode Type > Manager (their screen font scaling technology), text editing and program > launching is quite fast. Does anyone have a good idea of why the NeXT was > so slow? > > Steven Miller > Vancouver Division > Hewlett Packard the launch of applications that were written in Objective-C IS slow. this is because O-C has to dearchive its objects from disk. O-C isn't the most efficient language i've seen. i have seen worse. but that's the problem. if you use sed, awk, grep and sh/csh things like that you'll not think it's slow. ==+==+==+==+==+==+==+==+==+==+==+==+==+== ..umbc3.umbc.edu!tron!kgw2!dennisg + Dennis P. Glatting + Xetron Corporation + Cincinnati, Ohio + I want my own NeXT, 16 MB RAM, + 660 MB SCSI, NeXT Printer. + Accepting Donations. ==+==+==+==+==+==+==+==+==+==+==+==+==+==
rca@brunix (Ronald C.F. Antony) (12/01/89)
> I noticed that it took a very long time to load and that >scrolling and moving throught the document was very slow. This surprised >me considering the amount of horsepower the NeXT machine is supposed to have. >When going to the bottom of the ducument, it took about 5-10 seconds to redraw >the screen. The time to start up the application is mostly due to the fact that there are a lot of objects to be initialized or loaded in from disk. The time it takes to scroll down to the bottom of a document is a question of how much the application buffers graphically. As everything is presented in Postscript, it takes a while to recalculate the graphics (there are no bitmap-fonts nor approximations of postscript-fonts, it's the real thing but this has it's price...) Compared to X it is still fast :) Ronald ------------------------------------------------------------------------------ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." - Bernhard Shaw | rca@cs.brown.edu or antony@cogsci.bitnet
chari@nueces.cactus.org (Chris Whatley) (12/02/89)
rca@brunix (Ronald C.F. Antony) writes: >The time to start up the application is mostly due to the fact >that there are a lot of objects to be initialized or loaded in >from disk. It is significantly better with more memory. Less copying and allocation on the one disk. >As everything is presented in Postscript, it takes a while to >recalculate the graphics (there are no bitmap-fonts nor >approximations of postscript-fonts, it's the real thing but >this has it's price...) What is this then? nueces:/NextLibrary/Fonts/bitmap> ls total 519 34 Courier-Bold.bepf 1 Lexi.bepf 35 Courier-BoldOblique.bepf 33 Ohlfs.bepf 33 Courier-Oblique.bepf 30 Symbol.bepf 33 Courier.bepf 35 Times-Bold.bepf etc ..... >Compared to X it is still fast :) That's for sure.... -- Chris Whatley Work: chari@pelican.ma.utexas.edu (NeXT Mail) (512/471-7711 ext 123) Play: chari@nueces.cactus.org (NeXT Mail) (512/499-0475) Also: chari@emx.utexas.edu
dtgcube (Edward Jung) (12/02/89)
rca@brunix (Ronald C.F. Antony) writes: >As everything is presented in Postscript, it takes a while to >recalculate the graphics (there are no bitmap-fonts nor >approximations of postscript-fonts, it's the real thing but >this has it's price...) That is not true. Display Postscript, as an optimization, supports bitmapped fonts and a (rather) complex set of operations to map regular fonts (and their spacings) to their bitmap representations. On the NeXT machine, this is generally done only at point sizes less than 24. You do not *have* to have bitmapped fonts. Adobe recently released some extensions to DPS concerning new bitmap spacing caching and use operators (extensions to their existing ones). A simple test to see the difference between bitmap and regular fonts on the Cube is to use rotated text at a non-90 degree increment (map text to a circle, for example). This will force the use of the outline definitions. -- Edward Jung The Deep Thought Group, L.P. BIX: ejung 3400 Swede Hill Road NeXT or UNIX mail Clinton, WA. 98236 UUCP: uunet!dtgcube!ed Internet: ed@dtg.com
ed@DTG.COM (Edward Jung) (12/04/89)
In article <129@kgw2.UUCP>, dennisg@kgw2 (Dennis Glatting) writes: > >the launch of applications that were written in Objective-C IS slow. this >is because O-C has to dearchive its objects from disk. O-C isn't the most >efficient language i've seen. i have seen worse. but that's the problem. >if you use sed, awk, grep and sh/csh things like that you'll not think >it's slow. > Launching of Objective-C applications is slow. Interface Builder takes time to set up objects from its control file, but more importantly, the entire Objective-C-style class run-time structure must be created. This requires initialization messaging, management of the hierarchy, etc. Contrast this with certain other hybrid object languages where some of this is pushed to compile time. Objective-C's way of doing it offers some additional flexibility (like the ability to change classes and hierarchy on the fly, and for other languages to use the same run-time class system). As of 1.0, the initialization messaging is performed lazily; classes (and their superclasses) are initialized when called. Previously all classes were sent initialization messages at the start of the application. Of course you can still depend on superclass initialization to occur before subclass initialization. Sacrificing the run-time system, however, would cause the loss of many of the "neat" features of the Cube. -- Edward Jung The Deep Thought Group, L.P. BIX: ejung 3400 Swede Hill Road NeXT or UNIX mail Clinton, WA. 98236 UUCP: uunet!dtgcube!ed Internet: ed@dtg.com