From: Victor Shepelev <vshepelev@...>
Date: 2006-05-23T02:38:11+09:00
Subject: Re: Zed and Luis drop the bomb on Ruby's poor performance

From: ara.t.howard@noaa.gov [mailto:ara.t.howard@noaa.gov]
> > Makes sense. But.
> > I'd like to think about things like "reasonable slow" and "unreasonable
> > slow"; and Ruby sometimes is just __unreasonable__ slow. Here are some
> > examples:
> >
> > * I'm working with custom UI library, which is based on HTML (namely, on
> > terrainformatica.com/htmlayout). There are a large amount of objects
> created
> > corresponding to DOM tree nodes ("large" means thousands) and profiler
> says,
> > that one of the slowest operation is Class#new - is it normal?
> 
> devil's advocate: yes it makes sense that 'new' is slow.  it's generally
> slow
> in all langs, including c++ (where stl insertion causes 3 of ctors and the
> profiler will show this) and perl, which is claimed faster than ruby but,
> when
> objects are used, crawls compared to ruby because object creation is so
> bad in
> it.  the fact that object creation is so slow is why people historically
> don't
> represent chars as objects in text editors.  that said, perhaps it can be
> sped
> up - at least this is a good, concrete example!

Caugh... I've thought, that the main reason not to have an object for each
char is memory reason... But I can miss.
BTW, I was the C++ guy before Ruby, and I've never seen object creation took
a noticeable amount of performance. As well as other "simple core"
operations, like working with numbers and the same stuff.
Hence my astonishement, when after optimizing, optimizing, optimizing my
program with large UI and DB operations I see the top time-eating methods is
not UI, not DB, not sorting or filtering large arrays, but dumb stuff like
Fixunum#+ or Class#new.
 
> i can't
> think of a better way than to post some specific code and see what people
> can
> do with it.  history has shown that posting such challenges to the list
> yields
> at least an order of magnitude speed-up, if it doesn't i'd say you are
> correct - anyone have an example less than 100 lines or so we can play
> with?
> without an example i'm afraid this discussion will be little more than hot
> air.  let's get something real to work with, prove that it is
> 'unreasonably'
> slow, and then discuss.

OK, maybe later. Right now I haven't any "small function which is too slow",
but entire program works with unacceptable speed.
On my old Celeron 900 I can hardly debug it (but even on more modern 1500+
and 2000+ machines, which are normal in Ukraine, it also works slow).

> -a

Victor.