Forum: Ruby Making Ruby faster with Judy

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tomasz W. (Guest)
on 2007-02-27 03:32
(Received via mailing list)
I tried to optimize Ruby a bit more. The results vary quite a lot with
benchmarks,
but typical improvement is about 5% less time and 4% less memory.

More about it:
* http://t-a-w.blogspot.com/2007/02/ruby-and-judy.html
And a patch against Ruby 1.8.2-p12:
* http://zabor.org/taw/ruby-performance-patch-judy-2...
Mauricio F. (Guest)
on 2007-02-27 12:19
(Received via mailing list)
On Tue, Feb 27, 2007 at 10:31:49AM +0900, Tomasz W. wrote:
> I tried to optimize Ruby a bit more. The results vary quite a lot with
> benchmarks, but typical improvement is about 5% less time and 4% less
> memory.
>
> More about it:
> * http://t-a-w.blogspot.com/2007/02/ruby-and-judy.html
> And a patch against Ruby 1.8.2-p12:
> * http://zabor.org/taw/ruby-performance-patch-judy-2...

I wrote a naïve patch to use Judy for ruby's internal tables in 2002;
unlike
yours, it replaced all st_tables IIRC, but some of the feedback from
Judy's
author might still apply, see [48365].

matz took a look at Judy last year, see
http://www.rubyist.net/~matz/20060628.html
He seemed pretty excited about it, but the license (LGPL) would make
integration a bit cumbersome.

Normally, a patch like this should be tested in HEAD before it gets in
the 1.8
branch, but it's knu's call, of course.

PS.  please don't include all of configure when just configure.in will
do ;)
This topic is locked and can not be replied to.