murthy@svax.UUCP (03/24/87)
I got the Xtool distribution from decwrl recently, and playing around with the xedit and xmh, I noticed that they both are EXTREMELY slow. I was running my server on an RT, and running the applications on a uVax (4.3bsd). The first thing I noticed was that xmh couldn't understand how to show a message (I hit the view button, and no message showed up in the edit window). In fact, nothing I tried could get it to display a message. Perhaps I just wasn't trying enough things. At any rate, the Xtool toolkit appears to be GODAWFULLY slow. And I do mean SLOW. The xmh distribution was slower than GNUemacs remote, and the xedit application was pathetically slow. I really don't understand why they were so slow, but if this is the case with all the code that is written for this new toolkit, it seems like there is no hope if it becoming widespread. Now, I know that people are going to flame me for saying that, but consider that I basically had a uVaxII to myself, and xedit, a "toy" application, was still too slow for me to consider using it as a real tool. So: does anybody else out there have experience with the new toolkit, and have any opinions about its speed/lack thereof? --chet-- In Real Life: Chet Murthy ARPA: murthy@svax.cs.cornell.edu SnailMail: Chet Murthy Gaslight Village Apts 21-B Uptown Road Ithaca, NY 14850 Office: 4162 Upson (607) 255-2219 MaBellNet: (607)-257-5709 -- --chet-- In Real Life: Chet Murthy ARPA: murthy@svax.cs.cornell.edu SnailMail: Chet Murthy Gaslight Village Apts 21-B Uptown Road Ithaca, NY 14850 Office: 4162 Upson (607) 255-2219 MaBellNet: (607)-257-5709
mlandau@Diamond.UUCP (03/25/87)
Actually, I was more disturbed by the all-the-world's-a-Vax style of
the code and the NULL pointer dereferences scattered here and there.
Needless to say, neither to toolkit nor any of the sample programs
work on my 68020 machine.
In all fairness, though, Ram was quite clear about this being a
pre-release not known to work on non-Vax machines, and quite polite
when I sent him a note expressing my disappointment that such a
common portability trap should pervade the code. Perhaps the next
release (due in about 6 weeks?) will take care of some of the
performance and portability problems, as well as conforming to the
new widget semantics?
--
Matt Landau BBN Laboratories, Inc.
mlandau@diamond.bbn.com 10 Moulton Street, Cambridge MA 02238
...seismo!diamond.bbn.com!mlandau (617) 497-2429smokey@DECWRL.DEC.COM.UUCP (03/25/87)
Chet: As one of the designers of the Xtoolkit I feel compelled to reply. Sounds like you are having a good deal of finger trouble since there a small numbers of hundreds of folks who are using xmh as their only interface to mail. However your points are well taken. The V10 version of the Xtool kit painfully slow. Not on purpose but as a consequence of what it is. It was and still is a prototype of a toolkit to be provided with X V11. It was built to try out and prove or disprove our ideas. It has been very useful in that role. We have spent little or no time on performance tuning because the standard answer is always "X version 11" fixes that! We know that life is never that simple and will inevitably spent mucho time on performance. The V11 version is comming along. Not as quickly as we would like but it is turning over. I could argue that the current version is, infact useful, since a large number of people are using it, but that is begging the question. Your points are fundamentally correct and we would only be arguing about degree. I can only ask that you use the V10 toolkit for what it is. A prototype that will give you and others a head start in experiencing (at the functional level) what we hoping will be a solid framework for building applications and environments. Smokey...
jensen@winery.DEC.COM.UUCP (03/26/87)
I am in the process of implementing a complex application based on Xtoolkit. I have not observed the performance degradation you mention. The additional overhead in basic event dispatching is negligable: I have timed mouse dragging routines using bare X and Xt and found the differences too small to notice. It is true that certain parts of Xt (the Resource Manager in particular) could be implemented more efficiently, but this tends to affect startup time more than run-time. Given that Xt is somewhat of a prototype (in the sense that X10 was a prototype), it is not too surprising that not all of the code is tight. There are also places where additional code had to be written to simulate X11 functionality not available under X10. The fact that an application based on Xt is slow does not necessarily imply that Xt is the problem; it could be other parts of the application unrelated to the display code. In conclusion, I have found Xt to be extremely useful for the particular application I am writing. The library of Widgets saves me from re-inventing several wheels. More importantly, the Widget abstraction makes the code much easier to read, since I can "hide" the graphics specific code (which tends to be ratty) inside widget-private data & routines. Other facilities such as Context & Resource management are useful by themselves. Writing code for Xt is a big improvement over bare X. If my experience is typical, reports of Xt's demise are highly exaggerated. /Paul Jensen Digital Equipment Corp Western Area Operations Santa Clara, CA any opinions expressed above are solely my own, etc...