[rescue] Re: [SunHELP] Solaris 9, First thoughts

Patrick Giagnocavo patrick at zill.net
Sat Jan 19 22:37:22 CST 2002


On Sat, Jan 19, 2002 at 11:21:12PM -0500, Joshua D Boyd wrote:
> On Sat, Jan 19, 2002 at 10:15:20PM -0500, Dave McGuire wrote:
> > On January 19, Joshua D Boyd wrote:
> >   This surprises me very, very much...it's SO huge and SO slow, I
> > don't know how ANYONE can write C code like that.  It's doing a lot,
> > but it's not like it's all THAT much.
> 
> Well, I haven't profiled it, so I'm just spitting ideas, but I think it might
> have something to do with trying to use ORBit for message passing between 
> objects rather than call them directly.  Or, maybe it has something to do 

Message passing, in a good implementation, is not much slower than
function calls.

> with how sloppy they can be.  Alan Cox profiled one of the worst programs
> (Nautilus) and found that it kept reloading the same font file hundreds and
> hundreds of times.  I don't know what else could be causing problems, but
> just watching the output from pan is extremely appaling.  In a typical pan
> session, hundreds of asserts fail.

This would be much more likely as an explanation.  Sloppy code +
unfamiliarity with "the X Way" = slowness.

> To say that lisp is slow is a misunderstanding.  In reality, there is little
> reason that lisp can't be just as fast as C, if not faster.  It really just
> depends on how dedicated you are to continueing to use lisp because to wring
> the last bit of speed out, you have to do things like turn off GC and turn
> off type checking and modify the compiler to use the latest sets of multimedia
> instructions. 

Lisp is slow.  But it shouldn't matter since the best use is as a
scripting language on top of a faster, compiled runtime, such as
emacs.  As long as the core routines are fast, you're ok.

./patrick



More information about the rescue mailing list