[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