From: Stephen Bannasch Date: 2006-05-23T01:49:32+09:00 Subject: Re: Zed and Luis drop the bomb on Ruby's poor performance Hi cr, You stated that this kind of comment is off the thread topic: >>I just want to point out why it doesn't (pragmatically) matter to me >>personally atm. > >Oops! Wrong thread! :-) > >cr But when you started the thread one of the questions you asked was: "Why aren't we talking about it all the time?" "it" being the performance issue. If this was not one of the topics you wished to discuss in this thread it would be better not to specifically ask about it. ---- I think we aren't talking about it all the time because most of us don't have the expertise to contribute to the design and programming of a Ruby byte-code compiler however I am closely following the progress of YARV. Here's a concrete example of something I am doing in Ruby that I would like to be faster: I am using REXML and ruby-spreadsheet to read XML archives of Blackboard courses (an e-learning platform) and to process the forum discussions to produce interesting (at least to the education researchers I work with) statistics of all kinds about the conversations learners have in our on-line courses. Right now it takes about 30s to process a BB archive and produce the excel report. I am VERY happy programming using the native ruby tools for parsing the BB XML and writing my object representations back out as excel worksheets. These libraries are almost trivial to acquire (gem for the spreadsheet) and to use. However if I was to instead make an interactive application I'd like the process to be sped up by about 10x. I could use the ruby bindings for the C libxml library if I need to but I'd rather stay totally in Ruby. Until Ruby 2.0 is available I am quite happy that if I need the performance I can use a C library to speed up the slow parts. Something practical: I'll test my relatively simple app with the latest YARV and post here and to the YARV folks my results. FYI: Downloading and installing YARV: http://www.atdot.net/yarv/#i-4 -- - Stephen Bannasch Concord Consortium, http://www.concord.org