From jonathan.w.meyer at gmail.com Fri Jun 1 01:38:16 2007 From: jonathan.w.meyer at gmail.com (Jonathan Meyer) Date: Fri, 1 Jun 2007 00:38:16 -0500 Subject: [Chirb] contract opportunity Message-ID: <350adff30705312238w7a29c0cbuf3849dd851241695@mail.gmail.com> Hi Chicago Ruby group, I am currently working with a group called usmack.com and they are in need of programmers for their site (currently done in Rails). Whoever works with them will be picking up on the development of the site from where their previous group left off. If you would have any interest in working with them on a contract basis or otherwise, please let me know and I can put you in touch with them. Thanks! -- Jonathan W. Meyer jonathan.w.meyer at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070601/0a4b0de7/attachment-0001.html From lance at killswitchcollective.com Fri Jun 1 10:20:31 2007 From: lance at killswitchcollective.com (Lance Ennen) Date: Fri, 1 Jun 2007 09:20:31 -0500 Subject: [Chirb] contract opportunity In-Reply-To: <350adff30705312238w7a29c0cbuf3849dd851241695@mail.gmail.com> References: <350adff30705312238w7a29c0cbuf3849dd851241695@mail.gmail.com> Message-ID: Jonathan, Thanks for the email! I would like to discuss this project with you. I am interested in helping out outside of work. Let me know a little more about the project and the status of the development. Thanks!! Lance Ennen Software Developer The Killswitch Collective, LLC 125 S. Racine 1st Floor East Chicago, IL 60607 T+ 312 421 3606 W+ www.killswitchcollective.com On Jun 1, 2007, at 12:38 AM, Jonathan Meyer wrote: > Hi Chicago Ruby group, > > I am currently working with a group called usmack.com and they are > in need of programmers for their site (currently done in Rails). > Whoever works with them will be picking up on the development of > the site from where their previous group left off. > > If you would have any interest in working with them on a contract > basis or otherwise, please let me know and I can put you in touch > with them. > > Thanks! > > -- > Jonathan W. Meyer > jonathan.w.meyer at gmail.com > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070601/171a27be/attachment.html From jason at hostedlabs.com Mon Jun 4 12:12:07 2007 From: jason at hostedlabs.com (Jason Rexilius) Date: Mon, 04 Jun 2007 11:12:07 -0500 Subject: [Chirb] BARcamp Chicago 2007 June 23-24 Message-ID: <466439D7.3040803@hostedlabs.com> Hi Everyone! Wanted to update you all on BARcamp and ask for some feedback. The site (http://barcampchicago.com/) has been updated with the basic info on date and location. Its June 23-24 at 1464 n milwaukee. There are talks scheduled and some events planned but I wanted to ask you all what types of things you might want to see or hear about and to look for volunteers to run some code sprints or other projects. I also wanted to ask people to sign up on the wiki as attendees. I'm a little concerned that we may run out of space even though the venue is bigger than last years. I want to get a feeling for how much need there may be for a "spill over" venue. Looking forward to seeing you all at BARcamp and drop me a line if you have any comments, questions, ideas! -jason From brendan at usergenic.com Tue Jun 5 08:01:54 2007 From: brendan at usergenic.com (Brendan Baldwin) Date: Tue, 5 Jun 2007 07:01:54 -0500 Subject: [Chirb] "Named Captures" for Regular Expressions Message-ID: <7e757dc00706050501o6a583fcbn99e9b1b24e159132@mail.gmail.com> Hey Guys, I wrote up a tiny blog post summarizing my talk on my Named Captures library for Regular Expressions last night: http://www.rubyfu.com/2007/06/named-captures-for-regular-expressions.html And here's a quick link right to the code: http://usergenic.com/svn/public/ruby/fu/trunk/lib/regexp/named_captures.rb Just wanted to pass that on since I kind of rushed through the URL last night. --Brendan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070605/a21680a2/attachment.html From jcroneme at thoughtworks.com Tue Jun 5 11:16:29 2007 From: jcroneme at thoughtworks.com (Josh Cronemeyer) Date: Tue, 5 Jun 2007 10:16:29 -0500 Subject: [Chirb] "Named Captures" for Regular Expressions In-Reply-To: <7e757dc00706050501o6a583fcbn99e9b1b24e159132@mail.gmail.com> Message-ID: Thanks brendan! I really enjoyed the regex talk last night. I'll give the blog a look. And thanks to everyone who talked and participated in last night's discussion. I definately learned some new stuff. Josh Cronemeyer chicagogroup-members-list-bounces at rubyforge.org wrote on 06/05/2007 07:01:54 AM: > Hey Guys, > > I wrote up a tiny blog post summarizing my talk on my Named Captures > library for Regular Expressions last night: > > http://www.rubyfu.com/2007/06/named-captures-for-regular-expressions.html > > And here's a quick link right to the code: > > http://usergenic.com/svn/public/ruby/fu/trunk/lib/regexp/named_captures.rb > > Just wanted to pass that on since I kind of rushed through the URL last night. > > --Brendan > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070605/5b09bddb/attachment.html From arussell at pathf.com Tue Jun 5 16:17:19 2007 From: arussell at pathf.com (Amy Russell) Date: Tue, 5 Jun 2007 15:17:19 -0500 Subject: [Chirb] Senior Ruby Developer Message-ID: <009a01c7a7ae$84a8c6b0$7c53a8c0@antec1> Pathfinder Associates, a leading outsourced software product development company, is looking for an experienced Ruby on Rails developer join our application development team. This position will collaborate with business analysts, interaction designers, and other developers to build innovative web applications. We could go into a lot of requirements for this position, but ultimately what we're looking for can be boiled down into one sentence: We're looking for radically strong developers who want to stretch in new directions, who can speak and write as well as they email and IM, and who play well with others. That being said, we do need to state a few requirements, such as: * Exceptional skills in Ruby on Rails, DHTML/CSS, AJAX, Postgres, MySQL and Linux * Strong experience in OOD, web technologies and architectures * Practical experience in agile development methodologies (Scrum or eXtreme programming) * A passion for technology and can pick up new ideas and skills easily. Pathfinder values smart, motivated people who take pride in their work. If you thrive on the challenge of developing great software and working with diverse, multidisciplinary teams, send your resume or apply online now. Send all cover letters and resumes to us at:careers at pathf.com subject Ruby on Rails Developer using Reference Number 0602 in the subject line. About Pathfinder Pathfinder designs and develops people-friendly, commercial grade software and web applications for enterprises and software vendors. Pathfinder's approach integrates user experience design (UXD) with agile development to improve software quality and accelerate development. Pathfinder has offices in Chicago and New York and offshore delivery centers in India and the Philippines. For more information, call +1.312.372.1058, email info at pathf.com, or visit http://www.pathf.com . Travel required: none Telecommute: no Existing H1 residents in the US welcome! 1H Amy Russell Pathfinder Associates, LLC Office Coordinator arussell at pathf.com 312-372-1058 x6008 www.pathf.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070605/9c339cad/attachment-0001.html From ryan at platte.name Wed Jun 6 20:30:35 2007 From: ryan at platte.name (Ryan Platte) Date: Wed, 6 Jun 2007 19:30:35 -0500 Subject: [Chirb] Job postings? Message-ID: <2f1a1dcb0706061730w6bd0ca7ch66e0851254f67263@mail.gmail.com> Hi all, You may or may not know I'm the list admin. So far I've taken a laissez-faire approach to job postings -- what do you all think? Should we just let them go as we've been doing? Or would you prefer we set up a separate list for this purpose? If we went that route I'd just copy this list's membership and let people unsubscribe from the job postings list. Please share your thoughts. -- Ryan Platte -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070606/9c852a54/attachment.html From mrnicksgirl at gmail.com Wed Jun 6 22:01:44 2007 From: mrnicksgirl at gmail.com (Nola Stowe) Date: Wed, 6 Jun 2007 21:01:44 -0500 Subject: [Chirb] Job postings? In-Reply-To: <2f1a1dcb0706061730w6bd0ca7ch66e0851254f67263@mail.gmail.com> References: <2f1a1dcb0706061730w6bd0ca7ch66e0851254f67263@mail.gmail.com> Message-ID: <43e95380706061901s2897b755s2060191ac3d4273c@mail.gmail.com> I think I'd like a separate list for job postings. On 6/6/07, Ryan Platte wrote: > > Hi all, > > You may or may not know I'm the list admin. So far I've taken a > laissez-faire approach to job postings -- what do you all think? Should we > just let them go as we've been doing? Or would you prefer we set up a > separate list for this purpose? If we went that route I'd just copy this > list's membership and let people unsubscribe from the job postings list. > > Please share your thoughts. > > -- > Ryan Platte > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > -- http://rubygeek.com - my blog featuring: Ruby, PHP and Perl http://DevChix.com - boys can't have all the fun -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070606/19d268f0/attachment.html From cstejerean at gmail.com Wed Jun 6 22:13:15 2007 From: cstejerean at gmail.com (Cosmin Stejerean) Date: Wed, 6 Jun 2007 21:13:15 -0500 Subject: [Chirb] Job postings? In-Reply-To: <2f1a1dcb0706061730w6bd0ca7ch66e0851254f67263@mail.gmail.com> References: <2f1a1dcb0706061730w6bd0ca7ch66e0851254f67263@mail.gmail.com> Message-ID: <383bbcce0706061913o455c6dbdk657179ef3620197f@mail.gmail.com> So far the job postings haven't been coming through often enough to be a nuissance so I don't think I mind either way. Would it be possible to simply flag each job related message by simply adding something like [JOB] to the title without creating a separate list? That way folks can just ignore them or setup a filter to make them go away altogethr. - Cosmin On 6/6/07, Ryan Platte wrote: > > Hi all, > > You may or may not know I'm the list admin. So far I've taken a > laissez-faire approach to job postings -- what do you all think? Should we > just let them go as we've been doing? Or would you prefer we set up a > separate list for this purpose? If we went that route I'd just copy this > list's membership and let people unsubscribe from the job postings list. > > Please share your thoughts. > > -- > Ryan Platte > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070606/444d59a6/attachment.html From natebkirby at yahoo.com Wed Jun 6 22:20:28 2007 From: natebkirby at yahoo.com (Nate Kirby) Date: Thu, 07 Jun 2007 10:20:28 +0800 Subject: [Chirb] Job postings? In-Reply-To: <383bbcce0706061913o455c6dbdk657179ef3620197f@mail.gmail.com> References: <2f1a1dcb0706061730w6bd0ca7ch66e0851254f67263@mail.gmail.com> <383bbcce0706061913o455c6dbdk657179ef3620197f@mail.gmail.com> Message-ID: <46676B6C.9040900@yahoo.com> I like this idea - if it is possible. The postings have not been abusive or excessive and so I have no objection to what is currently happening. I have already got a lead from this list - so I kinda like it. Blessings, Nate Cosmin Stejerean wrote: > So far the job postings haven't been coming through often enough to be > a nuissance so I don't think I mind either way. Would it be possible > to simply flag each job related message by simply adding something > like [JOB] to the title without creating a separate list? That way > folks can just ignore them or setup a filter to make them go away > altogethr. > > - Cosmin > > On 6/6/07, *Ryan Platte* > > wrote: > > Hi all, > > You may or may not know I'm the list admin. So far I've taken a > laissez-faire approach to job postings -- what do you all think? > Should we just let them go as we've been doing? Or would you > prefer we set up a separate list for this purpose? If we went that > route I'd just copy this list's membership and let people > unsubscribe from the job postings list. > > Please share your thoughts. > > -- > Ryan Platte > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > ------------------------------------------------------------------------ > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.472 / Virus Database: 269.8.11/837 - Release Date: 6/6/2007 2:03 PM > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070607/2fb2fedb/attachment.html From sarah at fabled.net Wed Jun 6 22:40:38 2007 From: sarah at fabled.net (Sarah Gray) Date: Wed, 06 Jun 2007 21:40:38 -0500 Subject: [Chirb] Job postings? In-Reply-To: <46676B6C.9040900@yahoo.com> References: <2f1a1dcb0706061730w6bd0ca7ch66e0851254f67263@mail.gmail.com> <383bbcce0706061913o455c6dbdk657179ef3620197f@mail.gmail.com> <46676B6C.9040900@yahoo.com> Message-ID: <46677026.7040307@fabled.net> Agreed. I'd keep them on with the [JOB] flag added to the title (formally or informally by asking folks to use it). They're hardly problematic and can lead to serendipity in the way that subscribing to a separate list might not. Nate Kirby wrote: > I like this idea - if it is possible. > > The postings have not been abusive or excessive and so I have no > objection to what is currently happening. I have already got a lead > from this list - so I kinda like it. > > Blessings, > Nate > > Cosmin Stejerean wrote: >> So far the job postings haven't been coming through often enough to >> be a nuissance so I don't think I mind either way. Would it be >> possible to simply flag each job related message by simply adding >> something like [JOB] to the title without creating a separate list? >> That way folks can just ignore them or setup a filter to make them go >> away altogethr. >> >> - Cosmin >> >> On 6/6/07, *Ryan Platte* > >> wrote: >> >> Hi all, >> >> You may or may not know I'm the list admin. So far I've taken a >> laissez-faire approach to job postings -- what do you all think? >> Should we just let them go as we've been doing? Or would you >> prefer we set up a separate list for this purpose? If we went >> that route I'd just copy this list's membership and let people >> unsubscribe from the job postings list. >> >> Please share your thoughts. >> >> -- >> Ryan Platte >> _______________________________________________ >> ChicagoGroup-Members-List at rubyforge.org >> >> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> ChicagoGroup-Members-List at rubyforge.org >> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list >> ------------------------------------------------------------------------ >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.472 / Virus Database: 269.8.11/837 - Release Date: 6/6/2007 2:03 PM >> > ------------------------------------------------------------------------ > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070606/1078b88e/attachment.html From sean.seanlynch at gmail.com Thu Jun 7 09:22:24 2007 From: sean.seanlynch at gmail.com (Sean Lynch) Date: Thu, 7 Jun 2007 08:22:24 -0500 Subject: [Chirb] Job postings? In-Reply-To: <2f1a1dcb0706061730w6bd0ca7ch66e0851254f67263@mail.gmail.com> References: <2f1a1dcb0706061730w6bd0ca7ch66e0851254f67263@mail.gmail.com> Message-ID: <40651cc90706070622o39db8ff8lb14d434fcddd74b1@mail.gmail.com> Other lists I'm on request job postings have [Job Posting] in the subject area. I don't think the job postings have been too frequent, and they have been for jobs dealing with Ruby or Rails, so I don't think they are spam. If we start getting flooded by random job postings from clueless recruiters, I'm all for the separate list. For now though, I don't mind what I have seen. Thank you for asking! On 6/6/07, Ryan Platte wrote: > Hi all, > > You may or may not know I'm the list admin. So far I've taken a > laissez-faire approach to job postings -- what do you all think? Should we > just let them go as we've been doing? Or would you prefer we set up a > separate list for this purpose? If we went that route I'd just copy this > list's membership and let people unsubscribe from the job postings list. > > Please share your thoughts. > > -- > Ryan Platte > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > From danw at wellsoftware.com Thu Jun 7 09:53:28 2007 From: danw at wellsoftware.com (Dan Wellisch) Date: Thu, 07 Jun 2007 08:53:28 -0500 Subject: [Chirb] Job postings? Message-ID: <46680DD8.6060602@wellsoftware.com> Is it acceptable to post that you are looking for work as well as posting a job? -- Dan Wellisch Wellisch Software Technologies, Inc. www.wellsoftware.com 847-254-Well (9355) From carmelyne at pwim.com Thu Jun 7 10:35:29 2007 From: carmelyne at pwim.com (Carmelyne Thompson) Date: Thu, 07 Jun 2007 09:35:29 -0500 Subject: [Chirb] RE:Job postings? In-Reply-To: <46680DD8.6060602@wellsoftware.com> References: <46680DD8.6060602@wellsoftware.com> Message-ID: <466817B1.6060506@pwim.com> A few things: 1. I am voting + 1 on [JOB] 2. Two additional Sections on the CHIRB.org site 1. JOB POSTING 2. Directory of Freelancers Available for work I think those two things will help in a way. Thanks, Carmelyne http://www.devchix.com http://www.carmelyne.com Dan Wellisch wrote: > Is it acceptable to post that you are looking for work as well as > posting a job? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070607/5183d3ba/attachment.html From cstejerean at gmail.com Thu Jun 7 12:40:41 2007 From: cstejerean at gmail.com (Cosmin Stejerean) Date: Thu, 7 Jun 2007 11:40:41 -0500 Subject: [Chirb] Job postings? In-Reply-To: <466817B1.6060506@pwim.com> References: <46680DD8.6060602@wellsoftware.com> <466817B1.6060506@pwim.com> Message-ID: <383bbcce0706070940l307af745y8278d3ce08d964f5@mail.gmail.com> I second that. On 6/7/07, Carmelyne Thompson wrote: > > A few things: > > 1. I am voting + 1 on [JOB] > 2. Two additional Sections on the CHIRB.org site > 1. JOB POSTING > 2. Directory of Freelancers Available for work > > I think those two things will help in a way. > > Thanks, > Carmelyne > http://www.devchix.com > http://www.carmelyne.com > > > > Dan Wellisch wrote: > > Is it acceptable to post that you are looking for work as well as > posting a job? > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070607/0deb01fa/attachment.html From peter.fitzgibbons at gmail.com Fri Jun 8 06:59:01 2007 From: peter.fitzgibbons at gmail.com (Peter Fitzgibbons) Date: Fri, 8 Jun 2007 05:59:01 -0500 Subject: [Chirb] "Named Captures" for Regular Expressions In-Reply-To: References: <7e757dc00706050501o6a583fcbn99e9b1b24e159132@mail.gmail.com> Message-ID: <670a00380706080359m533287el7e1a28bfae976ac4@mail.gmail.com> Hey Brendan & All, I just did that lookup I suggested on Oniguruma, the regex engine that is in 1.9. Firstly, Oniguruma is now 1.8 safe, and there is more info and gem info at http://oniguruma.rubyforge.org/ Oniguruma adds named groups to the list, and does nothing about concatenation (+) If you don't get to it first, Brendan, I may take a crack at modding your extension to work with Oniguruma. Hope everyone has a good Friday! Peter Fitzgibbons On 6/5/07, Josh Cronemeyer wrote: > > > Thanks brendan! I really enjoyed the regex talk last night. I'll give > the blog a look. And thanks to everyone who talked and participated in last > night's discussion. I definately learned some new stuff. > > Josh Cronemeyer > > chicagogroup-members-list-bounces at rubyforge.org wrote on 06/05/2007 > 07:01:54 AM: > > > Hey Guys, > > > > I wrote up a tiny blog post summarizing my talk on my Named Captures > > library for Regular Expressions last night: > > > > > http://www.rubyfu.com/2007/06/named-captures-for-regular-expressions.html > > > > And here's a quick link right to the code: > > > > > http://usergenic.com/svn/public/ruby/fu/trunk/lib/regexp/named_captures.rb > > > > Just wanted to pass that on since I kind of rushed through the URL last > night. > > > > --Brendan > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > -- ------------------------------ Y2Cicadas - Chicago's worst weather report in 17 years ? ------------------------------ Peter Fitzgibbons -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070608/922948be/attachment.html From danw at wellsoftware.com Fri Jun 8 15:52:12 2007 From: danw at wellsoftware.com (Dan Wellisch) Date: Fri, 08 Jun 2007 14:52:12 -0500 Subject: [Chirb] Looking to do some XP/TDD in Rails Message-ID: <4669B36C.4080007@wellsoftware.com> Hello: I attended the Ruby On Rails meeting last Monday at ThoughtWorks in Chicago. I have been reading up on ROR and have done one prototype in it. I come from a Java background. Where is the best place to find contract work? Does anyone need a developer to help them on an assignment at this time? Thanks, Dan Wellisch -- Dan Wellisch Wellisch Software Technologies, Inc. www.wellsoftware.com 847-254-Well (9355) From brendan at usergenic.com Fri Jun 8 20:00:32 2007 From: brendan at usergenic.com (Brendan Baldwin) Date: Fri, 8 Jun 2007 19:00:32 -0500 Subject: [Chirb] "Named Captures" for Regular Expressions In-Reply-To: <670a00380706080359m533287el7e1a28bfae976ac4@mail.gmail.com> References: <7e757dc00706050501o6a583fcbn99e9b1b24e159132@mail.gmail.com> <670a00380706080359m533287el7e1a28bfae976ac4@mail.gmail.com> Message-ID: <7e757dc00706081700r5180ab51y40f104a094a01e5c@mail.gmail.com> That's very exciting! I'm going to have to check that out as soon as I can; Turns out there are still issues with $1 etc outside the caller's scope with my named_captures.rb library that require all kinds of tricks to work around, so thanks for this! -_Brendan On 6/8/07, Peter Fitzgibbons wrote: > > Hey Brendan & All, > > I just did that lookup I suggested on Oniguruma, the regex engine that is > in 1.9. > Firstly, Oniguruma is now 1.8 safe, and there is more info and gem info at > > http://oniguruma.rubyforge.org/ > > Oniguruma adds named groups to the list, and does nothing about > concatenation (+) > > If you don't get to it first, Brendan, I may take a crack at modding your > extension to work with Oniguruma. > > Hope everyone has a good Friday! > > Peter Fitzgibbons > > On 6/5/07, Josh Cronemeyer wrote: > > > > > > Thanks brendan! I really enjoyed the regex talk last night. I'll give > > the blog a look. And thanks to everyone who talked and participated in last > > night's discussion. I definately learned some new stuff. > > > > Josh Cronemeyer > > > > chicagogroup-members-list-bounces at rubyforge.org wrote on 06/05/2007 > > 07:01:54 AM: > > > > > Hey Guys, > > > > > > I wrote up a tiny blog post summarizing my talk on my Named Captures > > > library for Regular Expressions last night: > > > > > > http://www.rubyfu.com/2007/06/named-captures-for-regular-expressions.html > > > > > > > > And here's a quick link right to the code: > > > > > > http://usergenic.com/svn/public/ruby/fu/trunk/lib/regexp/named_captures.rb > > > > > > > > Just wanted to pass that on since I kind of rushed through the URL > > last night. > > > > > > --Brendan > > > _______________________________________________ > > > ChicagoGroup-Members-List at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > -- > ------------------------------ > Y2Cicadas - Chicago's worst weather report in 17 years ? > ------------------------------ > Peter Fitzgibbons > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070608/553528e3/attachment-0001.html From peter.fitzgibbons at gmail.com Fri Jun 8 20:39:36 2007 From: peter.fitzgibbons at gmail.com (Peter Fitzgibbons) Date: Fri, 8 Jun 2007 19:39:36 -0500 Subject: [Chirb] "Named Captures" for Regular Expressions In-Reply-To: <7e757dc00706081700r5180ab51y40f104a094a01e5c@mail.gmail.com> References: <7e757dc00706050501o6a583fcbn99e9b1b24e159132@mail.gmail.com> <670a00380706080359m533287el7e1a28bfae976ac4@mail.gmail.com> <7e757dc00706081700r5180ab51y40f104a094a01e5c@mail.gmail.com> Message-ID: <670a00380706081739p4f998518u7a89acbe3210d5ad@mail.gmail.com> Here's what I see, Since Oniguruma defines #new(str), and the match operand is =~, I guess there wouldn't be too much trouble in overriding #ogregexp= as alias to #new. WIth that in mind, maybe the + operand you worked out could simply be hanlded by #newing concatenated strings. That answer may resolve the $1 issue, since the parsing of backreference indexes can be performed before the match string (in String type) is converted to match code (whatever the internal type of /abc/ is?). Have fun! Peter On 6/8/07, Brendan Baldwin wrote: > > That's very exciting! I'm going to have to check that out as soon as I > can; Turns out there are still issues with $1 etc outside the caller's > scope with my named_captures.rb library that require all kinds of tricks to > work around, so thanks for this! > > -_Brendan > > On 6/8/07, Peter Fitzgibbons wrote: > > > > Hey Brendan & All, > > > > I just did that lookup I suggested on Oniguruma, the regex engine that > > is in 1.9. > > Firstly, Oniguruma is now 1.8 safe, and there is more info and gem info > > at > > > > http://oniguruma.rubyforge.org/ > > > > Oniguruma adds named groups to the list, and does nothing about > > concatenation (+) > > > > If you don't get to it first, Brendan, I may take a crack at modding > > your extension to work with Oniguruma. > > > > Hope everyone has a good Friday! > > > > Peter Fitzgibbons > > > > On 6/5/07, Josh Cronemeyer < jcroneme at thoughtworks.com > wrote: > > > > > > > > > Thanks brendan! I really enjoyed the regex talk last night. I'll > > > give the blog a look. And thanks to everyone who talked and participated in > > > last night's discussion. I definately learned some new stuff. > > > > > > Josh Cronemeyer > > > > > > chicagogroup-members-list-bounces at rubyforge.org wrote on 06/05/2007 > > > 07:01:54 AM: > > > > > > > Hey Guys, > > > > > > > > I wrote up a tiny blog post summarizing my talk on my Named Captures > > > > > > > library for Regular Expressions last night: > > > > > > > > http://www.rubyfu.com/2007/06/named-captures-for-regular-expressions.html > > > > > > > > > > > And here's a quick link right to the code: > > > > > > > > http://usergenic.com/svn/public/ruby/fu/trunk/lib/regexp/named_captures.rb > > > > > > > > > > > Just wanted to pass that on since I kind of rushed through the URL > > > last night. > > > > > > > > --Brendan > > > > _______________________________________________ > > > > ChicagoGroup-Members-List at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > _______________________________________________ > > > ChicagoGroup-Members-List at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > > > > > > -- > > ------------------------------ > > Y2Cicadas - Chicago's worst weather report in 17 years ? > > ------------------------------ > > Peter Fitzgibbons > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > -- ------------------------------ Y2Cicadas - Chicago's worst weather report in 17 years ? ------------------------------ Peter Fitzgibbons -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070608/ab7dd843/attachment.html From beau at open-source-staffing.com Sat Jun 9 15:11:46 2007 From: beau at open-source-staffing.com (Beau Gould) Date: Sat, 9 Jun 2007 15:11:46 -0400 Subject: [Chirb] [JOB] Rails or Python Engineer, Wilmette, IL | Salary: Open Message-ID: <001501c7aaca$0660a060$84cd9e42@BEAU> Rails or Python Engineer, Wilmette, IL | Salary: Open My client provides Fortune 500 marketers with customized, performance-based online customer acquisition solutions. They build long-term and large-scale marketing programs for select Clients, primarily in the financial services and communications industries, utilizing a closed-loop marketing process from campaign design and implementation to technology integration. This integrated approach has enabled my client to become the largest source of new customers from the online channel for most of their clients. Position Purpose: The Software Engineer is responsible for developing and deploying web-based applications and associated support programs as determined by internal and external client requirements. Primary Responsibilities: * Develop, deploy and maintain web-based applications by: * Gathering requirements from internal customers and end-users * Advising internal customers on the development resources and risks for requested functionality * Developing code using test-driven, object-oriented methodologies * Performing unit testing and integration tests * Participating in end-user acceptance testing * Incorporating end-user feedback into later iterations of the software * Document applications at the following levels: * System architecture * Source code * Administration and maintenance * End-user training and help Job Skills and Requirements: * Expert in development of web-based applications using primarily PHP5 and Python in an open-source development environment * Thorough understanding of common web and e-commerce concepts and technologies, such as: HTTP, SSL, JavaScript and variants, HTML and other client-side data formats (no graphic design skills required), XML and associated technologies, content management concepts, public-key cryptography, application and data security and privacy issues, basic TCP/IP networking * Excellent written and verbal communication skills * Ability to work well both within a team environment and independently * Highly self motivated * Comfortable working within a fast-paced, dynamic environment * Ability to prioritize and perform multiple tasks in time critical situations * Required to maintain a professional, respectful, friendly relationship with coworkers, clients and suppliers * Required to adhere to policies and procedures, confidences and contract requirements Education and/or Experience: * Bachelor's degree and/or 5 years experience relating to web-based software development * Minimum of 5 years experience developing, testing, deploying and maintaining interactive web applications in PHP environments, as well as command-line batch processing scripts in Python or PHP scripting languages * Minimum of 5 years experience with any SQL-based RDBMS (PostgreSQL experience is especially useful) in the form of writing efficient SQL queries and executing them via programming language interfaces * Object-oriented design experience a big plus, especially as related to PHP 5 development * Experience working with "agile" development methodologies, particularly Scrum teamwork and User Story development and estimation, a very big plus If you are local to the Chicago area and are authorized to work in the USA, please submit your resume and salary requirements to beau at open-source-staffing.com [Word or plain text preferred] Thank you, Beau J. Gould Open Source Staffing www.open-source-staffing.com beau at open-source-staffing.com From kevin at obtiva.com Tue Jun 12 09:42:40 2007 From: kevin at obtiva.com (Kevin Taylor) Date: Tue, 12 Jun 2007 08:42:40 -0500 Subject: [Chirb] [JOB] Agile Ruby Developer in Western Suburbs Message-ID: <744d5a650706120642t470d9130j9d75865053c899af@mail.gmail.com> We are looking for 1 full-time Ruby developer to work in our studio in Wheaton, IL. Do you: - thrive in an open, honest, and collaborative environment? Do you: - have at least 6 months of Ruby and 2 years of general coding experience? Do you: - want to work on multiple Ruby on Rails projects in a team environment? Do you: - gain satisfaction from teaching and mentoring others while growing your own skills? If you can answer yes to all of the above questions and you want to be part of a fast growing agile consulting team, send a resume and a short letter describing why you want to be considered. Obtiva is a rapidly growing agile consulting team where team members spend their time doing in-the-trenches software development leveraging our agile practices, training other developers in technology and methodology topics, and engaging in short-term, intensive technology/agile coaching. We are actively involved in the developer community and frequently sponsor our team members to present what we have learned at local and national conferences. Our client list is diverse and includes entertainment companies, retailers, hedge funds, and Web 2.0 startups. You will be working in our Wheaton office. We are located near I-88 and within walking distance of the train station. Please send to jobs at obtiva.com. www.obtiva.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070612/d791c59e/attachment.html From clarkware at gmail.com Wed Jun 13 11:11:22 2007 From: clarkware at gmail.com (clarkware at gmail.com) Date: Wed, 13 Jun 2007 09:11:22 -0600 Subject: [Chirb] The Rails Edge Conference in Chicago Message-ID: <4ac18fbf0706130811ib67aa4aq7afbf1854ea95a74@mail.gmail.com> We hope you'll join us for The Rails Edge conference coming to Chicago on August 23-25. This is the third running of this conference, put on by the same folks who run the Pragmatic Studio Rails and Ruby training events. We have another great lineup of speakers for you to enjoy: * Dave Thomas, author of "Agile Web Development with Rails" and "Programming Ruby" * Chad Fower, author of "Rails Recipes" and co-founder of Ruby Central, Inc. * Jim Weirich, creator of Rake, RubyGems, and other software you probably use daily * Marcel Molina Jr., a member of the Rails core team * Ezra Zygmuntowicz, co-founder of EngineYard and author of the upcoming Rails Deployment book * Stuart Halloway, co-author of "Rails for Java Programmers" and co-creator of the Streamlined framework * Justin Gehtland, co-author of "Rails for Java Programmers" and co-creator of the Streamlined framework * David Chelimsky, lead developer of RSpec since August 2006 * Mike Mangino, resident expert on REST and testing at Elevated Rails All of these speakers are available each day of the conference, so come get your questions answered! Throughout this single-track conference you'll keep up to date on timely topics including: * Metaprogramming Ruby * REST * Active Resource * Test-Driven Development * RSpec * Rails Deployment * JRuby * Writing Domain-Specific Languages * Ajax and RJS * Domain-Driven Design in Ruby * Refactoring Rails Applications Still wondering why you should attend? Check out some of the reviews from folks who attended previous Rails Edge conferences: http://blog.dangdev.com/2007/1/29/the-rails-edge/ http://www.mslater.com/2006/11/21/the-latest-on-ruby-on-rails http://www.luisdelarosa.com/2007/01/26/rails-edge-reston-day-1/ http://blog.viget.com/rails-edge-conference-highlights/ Both of the previous Rails Edge conferences sold out quickly, so reserve your seat and save $100 by registering before July 1st. Visit http://therailsedge.com for registration details. Thanks for your continued support! -- Mike Clark http://pragmaticstudio.com Ruby and Rails Training From natebkirby at yahoo.com Sat Jun 16 08:28:58 2007 From: natebkirby at yahoo.com (Nate Kirby) Date: Sat, 16 Jun 2007 21:28:58 +0900 Subject: [Chirb] JRuby performance In-Reply-To: References: <465BF078.8050808@yahoo.com> <465CC5FD.7030505@yahoo.com> <465D85AD.3010700@yahoo.com> Message-ID: <4673D78A.50001@yahoo.com> Peter, I don't like eating crow, but it is better than starving. The current results are (the I in this is not form me but a colleague) [Summation: Performance for CPU indicates JRuby is the way to go] ############################################### Here are the results: 1. Java is much faster than Ruby. Implementing the Hanoi algorithm in Java, either calling from JRuby or through RJB gains the hundreds of times of performance boost. At first I let the number of disks be 28, the same as last time I sent you, but this time only takes a few seconds. ------------------------------------------------------------------------------------ clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh Loaded suite test/functional/test_controller_test Started Number of disks: 28 Start Time: 1181985788.69547 Finish Time: 1181985796.42535 Time used: 7.72987794876099 seconds . Finished in 7.808512 seconds. 1 tests, 0 assertions, 0 failures, 0 errors ---------------------------------------------------------------------------- clive at epiphany:~/Desktop/performance$ ./jruby.sh Number of disks: 28 Start Time: 1181984655.81 Finish Time: 1181984659.713 Time used: 3.9030001163482666 seconds --------------------------------------------------------------------------------- 2. Since both only took a few seconds, I increased the number of disks to gain more accurate results, and found that calling Java code from JRuby is faster than calling through RJB: ------------------------------------------------------------------------------- clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh Loaded suite test/functional/test_controller_test Started Number of disks: 35 Start Time: 1181985899.15607 Finish Time: 1181986895.74254 Time used: 996.586473941803 seconds . Finished in 996.662218 seconds. ------------------------------------------------------------------------------- clive at epiphany:~/Desktop/performance$ ./jruby.sh Number of disks: 35 Start Time: 1181988594.084 Finish Time: 1181989376.494 Time used: 782.4099998474121 seconds ------------------------------------------------------------------------------------ A few notes: 1. I don't know how to use RJB in ruby without rails, so I created a rails project and wrote a functional test to host those code. The rjb.sh in the zip file is what I used to run the test. I used Java server VM to run the Java code. I wonder if there are more things to do to tune the performance of RJB. 2. For JRuby, I used all performance tuning methods I used last time, plus this time I used Java server VM. This can be seen in jruby.sh 3. hanoi.zip is the Java code I used. I have trouble in passing arguments of primitive types to Java, both in rjb and jruby, so I overloaded the method with arguments of classes. But in terms of performance comparison, I don't think that matters. ############################################## Needless to say we are investigation JRuby seriously now. If you want the source for these tests I can provide it. Blessing, Nate Peter K Chan wrote: > Nate, > Thanks for getting back to me. I haven't seen the source for > your benchmark, but I imagine that it may be doing some specific > processing that JRuby is slow at (i.e. looking at the method names, it > seems to be doing quite a bit of byte shuffling?). > > Also, just a guess, but the 8x difference worsening to 14x times > may be due to JVM startup cost (a real possibility; once you step into > single digit second run time). > > In any case, here is a link which explains how to tune JRuby for > performance, including how to disable Object Space and turn on compiler: > > http://www.headius.com/jrubywiki/index.php/Performance_Tuning > > Just to put things in context: JRuby shines when you are doing > integration with Java and long running server processes. One time > scripts may still be a sore point for the foreseeable future, simply > because of the JVM start-up and warm-up cost. > > Peter > > -----Original Message----- > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > Sent: Wednesday, May 30, 2007 9:10 AM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > This is the reponse I got: > > ************* > The JVM on my Ubuntu machine is Sun's: > > clive at epiphany:~$ java -version > java version "1.6.0" > Java(TM) SE Runtime Environment (build 1.6.0-b105) > Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) > > And I use the latest version of JRuby. I ran that piece of code with > profiling again on my machine, which is very old one, C Ruby took 2.72 > sec, JRuby took 22.78 sec. 8.375 times difference. > Then I changed the code, took out profiler, and printed out the start > time and finish time only, C Ruby took 0.27586 sec, JRuby took 4.074 > sec: 14.768360763 times difference. > > The attachment is the raw data. I did not: > -disable object space (I did some research, but have no idea of how to > do that. The hotspot server seemed to have some option about size of > object space, but I don't think it allows us to set the size to 0) > > -turn on the JRuby AOT or JIT compiler ( I have no idea of what that is) > > It seems that the performance under default setting is still bad. > > ************** > Blessings, > Nate > > Peter K Chan wrote: > >> Sure, Nate. >> >> I do concede that JRuby is not yet a Ruby drop in replacement, at >> > least not for running small scripts. It takes only 5 minutes to tweak > the performance, but it is still 5 minutes more than C Ruby. Where JRuby > really shines is in Java integration and scalability (e.g. running > multiple rails instances within a single JVM, connecting to a JDBC > database). > >> I would be very interested in seeing what kind of performance you get >> > for your evaluation. > >> Peter >> ________________________________________ >> From: chicagogroup-members-list-bounces at rubyforge.org >> > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > >> Sent: Tuesday, May 29, 2007 7:32 PM >> To: Chirb discussion list >> Subject: Re: [Chirb] JRuby performance >> >> Peter, >> >> I actually had someone else do it. I will forward your suggestions >> > along to them. I have had the impression in the past that individual > vendors VMs were often faster than Suns for their platform. That is > possibly in error, but in the late 90's it was not. > >> Thanks, >> Nate >> >> Peter K Chan wrote: >> Nate, >> Josh has already brought up most of what I was going to reply to >> > you, but let me just highlight these factors, which may explain your > performance result: > >> - Are you using a modern JVM, such as Sun 1.6.0, with hotspot/JIT >> > compilation? > >> - Did you disable object space? (Makes a huge 20% - 40% difference, I >> > disable it in all my apps) > >> - Did you pull the latest trunk or at least RC version of JRuby? >> - Did you turn on the JRuby AOT or JIT compiler? >> - I think that JRuby's set_trace_func is slow; therefore, if you use >> > profile.rb, you may be incurring large profiling cost (actually, > set_trace_func isn't working in current JRuby compiler, so you must have > been running JRuby in pure interpretive mode). > > >> Also, keep in mind that the benchmark result I linked to >> > include JVM startup time. If you consider that the JVM takes a few > seconds to fully warm up, and most benchmark finishes in a few seconds, > JRuby's result is even more impressive. > >> Don't take my word for it. Run your benchmark with the right >> > settings, and you can see for yourself. :) > >> Peter >> ________________________________________ >> From: chicagogroup-members-list-bounces at rubyforge.org >> > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Josh Cronemeyer > >> Sent: Tuesday, May 29, 2007 11:11 AM >> To: Chirb discussion list >> Subject: [Chirb] JRuby performance >> >> >> discussion moved from this thread: Re: [Chirb] time to rsvp for the >> > mystery meeting! W00t > >> Nate, >> >> I've heard alot of good stuff about jruby performance, not from just >> > peter. > >> >> [programmer at Mark ~]$ java --version >> java version "1.4.2" >> gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) >> >> I think you should run your tests with a real JVM (like sun's >> > implementation). You are using gij which is a java interpretor. GIJ is > a part of the GCJ project. GCJ is a very different beast than sun's > implementation. The idea behind GCJ is that java is compiled down to > your specific platform's machine code. So they bypass the jvm all > together. This sounds like it would be faster, but it really isn't for > many things because sun's just in time compilation can actually compile > the same code in different ways depending on context in order to > optimize execution. I'm not sure if Jruby uses runtime code loading or > generation (i wouldn't be surprised though). If that is the case GCJ is > SUPER slow for those types of operations because that is when the gij > interpreter kicks in. The interpreter is realizing no benefits from > optimization or compilation. > >> The short of it: I wouldn't call my tests definitive until I was using >> > sun's jvm. > >> Josh Cronemeyer >> >> chicagogroup-members-list-bounces at rubyforge.org wrote on 05/29/2007 >> > 04:20:56 AM: > >> >> Peter, >> >> I can take your word for it....or I can check the performance stats we >> just did a few weeks ago JRuby was 10x slower than ruby at the command >> line on a Fedora box. >> >> Nate >> >> STATS >> >> [programmer at Mark ~]$ java --version >> java version "1.4.2" >> gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) >> >> Copyright (C) 2006 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There >> > is NO > >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> > PURPOSE. > >> I did not change the default JVM. I used the Ruby project >> concatenating wav files and profiler to see the performance data. This >> is the result: >> Ruby: >> % cumulative self self total >> time seconds seconds calls ms/call ms/call name >> 10.24 0.13 0.13 238 0.55 1.13 >> > MonitorMixin.mon_exit > >> 7.09 0.22 0.09 238 0.38 2.27 >> > MonitorMixin.synchronize > >> 6.30 0.30 0.08 238 0.34 3.57 Logger#add >> 5.51 0.37 0.07 238 0.29 0.34 Logger:: >> Formatter#format_datetime >> 4.72 0.43 0.06 17 3.53 68.82 FileFormat:: >> WavFile#getInfo >> 4.72 0.49 0.06 203 0.30 0.69 Integer#times >> 3.94 0.54 0.05 238 0.21 0.42 Logger:: >> LogDevice#check_shift_log >> 3.15 0.58 0.04 238 0.17 0.25 >> > MonitorMixin.mon_release > >> 3.15 0.62 0.04 238 0.17 0.34 >> > MonitorMixin.mon_enter > >> 2.36 0.65 0.03 256 0.12 0.12 String#+ >> 2.36 0.68 0.03 87 0.34 0.57 FileFormat:: >> WavFile#dataPos >> 2.36 0.71 0.03 177 0.17 0.85 FileFormat:: >> WavFile#readBigNum >> 2.36 0.74 0.03 530 0.06 0.06 IO#getc >> 2.36 0.77 0.03 8 3.75 155.00 Array#each >> 2.36 0.80 0.03 476 0.06 0.06 Thread#current >> 2.36 0.83 0.03 238 0.13 0.13 >> > Logger#format_severity > >> 2.36 0.86 0.03 238 0.13 0.21 MonitorMixin. >> mon_check_owner >> 2.36 0.89 0.03 952 0.03 0.03 Thread#critical= >> 2.36 0.92 0.03 238 0.13 0.55 >> > Logger::Formatter#call > >> 1.57 0.94 0.02 476 0.04 0.04 Array#shift >> 1.57 0.96 0.02 1060 0.02 0.02 Fixnum#* >> 1.57 0.98 0.02 238 0.08 0.08 Module#=== >> 1.57 1.00 0.02 238 0.08 0.08 IO#stat >> 1.57 1.02 0.02 87 0.23 0.23 IO#readline >> 1.57 1.04 0.02 476 0.04 0.04 Fixnum#> >> 1.57 1.06 0.02 965 0.02 0.02 Fixnum#+ >> 0.79 1.07 0.01 17 0.59 2.94 FileFormat:: >> WavFile#extraParams >> 0.79 1.08 0.01 238 0.04 0.04 Kernel.nil? >> 0.79 1.09 0.01 240 0.04 0.04 Time#initialize >> 0.79 1.10 0.01 44 0.23 0.23 IO#putc >> 0.79 1.11 0.01 34 0.29 0.29 FileFormat:: >> WavFile#fileSize >> 0.79 1.12 0.01 238 0.04 0.59 >> > Logger#format_message > >> 0.79 1.13 0.01 34 0.29 0.29 IO#read >> 0.79 1.14 0.01 17 0.59 0.59 FileFormat:: >> WavFile#readBytes >> 0.79 1.15 0.01 238 0.04 0.04 Time#usec >> 0.79 1.16 0.01 238 0.04 0.04 >> > Kernel.block_given? > >> 0.79 1.17 0.01 238 0.04 2.31 >> > Logger::LogDevice#write > >> 0.79 1.18 0.01 18 0.56 0.56 FileFormat:: >> WavFile#bitPerSample >> 0.79 1.19 0.01 34 0.29 1.47 FileFormat:: >> WavFile#subChunk2Size >> 0.79 1.20 0.01 238 0.04 0.13 >> > MonitorMixin.mon_acquire > >> 0.79 1.21 0.01 238 0.04 0.04 Fixnum#< >> 0.79 1.22 0.01 238 0.04 3.61 Logger#info >> 0.79 1.23 0.01 18 0.56 1.67 FileFormat:: >> WavFile#sampleRate >> 0.79 1.24 0.01 325 0.03 0.03 Kernel.== >> 0.79 1.25 0.01 238 0.04 0.04 File::Stat#size >> 0.79 1.26 0.01 240 0.04 0.08 Time#now >> 0.79 1.27 0.01 344 0.03 0.03 Fixnum#== >> 0.00 1.27 0.00 2 0.00 0.00 IO#sync= >> 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: >> WavFile#byteRate >> 0.00 1.27 0.00 18 0.00 0.00 Class#new >> 0.00 1.27 0.00 17 0.00 0.00 Array#to_s >> 0.00 1.27 0.00 1 0.00 0.00 FileFormat:: >> FileConcat#initialize >> 0.00 1.27 0.00 18 0.00 0.00 IO#to_io >> 0.00 1.27 0.00 35 0.00 0.00 FileFormat:: >> WavFile#audioFormat >> 0.00 1.27 0.00 238 0.00 0.08 >> > Logger::Formatter#msg2str > >> 0.00 1.27 0.00 238 0.00 0.00 String#[] >> 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: >> WavFile#openFile >> 0.00 1.27 0.00 28 0.00 0.00 Fixnum#<< >> 0.00 1.27 0.00 56 0.00 0.00 Fixnum#>> >> 0.00 1.27 0.00 2 0.00 0.00 Logger:: >> LogDevice#create_logfile >> 0.00 1.27 0.00 298 0.00 0.00 IO#pos= >> 0.00 1.27 0.00 17 0.00 0.00 File#exist? >> 0.00 1.27 0.00 238 0.00 0.00 Thread#pass >> 0.00 1.27 0.00 238 0.00 0.00 NilClass#to_s >> 0.00 1.27 0.00 17 0.00 0.00 Array#<< >> 0.00 1.27 0.00 51 0.00 0.00 IO#eof? >> 0.00 1.27 0.00 9 0.00 2.22 FileFormat:: >> FileConcat#writeData >> 0.00 1.27 0.00 2 0.00 0.00 Time#to_s >> 0.00 1.27 0.00 17 0.00 0.00 >> > FileFormat::WavFile#exist? > >> 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: >> WavFile#chunkSize >> 0.00 1.27 0.00 238 0.00 0.00 >> > Kernel.respond_to? > >> 0.00 1.27 0.00 1 0.00 0.00 IO#new >> 0.00 1.27 0.00 238 0.00 0.00 Time#strftime >> 0.00 1.27 0.00 4 0.00 0.00 Fixnum#| >> 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: >> WavFile#blockAlign >> 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: >> WavFile#extraParamSize >> 0.00 1.27 0.00 6 0.00 0.00 FileTest.exist? >> 0.00 1.27 0.00 17 0.00 0.00 IO#open >> 0.00 1.27 0.00 355 0.00 0.00 Fixnum#- >> 0.00 1.27 0.00 239 0.00 0.00 Array#[] >> 0.00 1.27 0.00 18 0.00 1.67 FileFormat:: >> WavFile#numChannels >> 0.00 1.27 0.00 1 0.00 0.00 Array#size >> 0.00 1.27 0.00 20 0.00 0.00 IO#close >> 0.00 1.27 0.00 8 0.00 0.00 File#rename >> 0.00 1.27 0.00 87 0.00 0.00 String#index >> 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: >> WavFile#initialize >> 0.00 1.27 0.00 1 0.00 90.00 FileFormat:: >> FileConcat#concatFiles >> 0.00 1.27 0.00 2 0.00 0.00 Kernel.open >> 0.00 1.27 0.00 2 0.00 0.00 Integer#downto >> 0.00 1.27 0.00 4 0.00 0.00 FileFormat:: >> FileConcat#writeBytes >> 0.00 1.27 0.00 1 0.00 30.00 FileFormat:: >> FileConcat#concat_data_block >> 0.00 1.27 0.00 476 0.00 0.00 NilClass#nil? >> 0.00 1.27 0.00 20 0.00 0.00 File#initialize >> 0.00 1.27 0.00 478 0.00 0.00 String#% >> 0.00 1.27 0.00 2 0.00 0.00 Logger:: >> LogDevice#add_log_header >> 0.00 1.27 0.00 18 0.00 2.78 FileFormat:: >> WavFile#subChunk1Size >> 0.00 1.27 0.00 2 0.00 0.00 Logger:: >> LogDevice#shift_log_age >> 0.00 1.27 0.00 318 0.00 0.00 IO#write >> 0.00 1.27 0.00 238 0.00 0.00 String#<< >> 0.00 1.27 0.00 238 0.00 0.00 Kernel.is_a? >> 0.00 1.27 0.00 222 0.00 0.00 Fixnum#to_s >> 0.00 1.27 0.00 34 0.00 0.00 File#size >> 0.00 1.27 0.00 1 0.00 1270.00 #toplevel >> >> JRuby: >> % cumulative self self total >> time seconds seconds calls ms/call ms/call name >> 10.27 1.25 1.25 203 6.17 7.84 Integer#times >> 9.64 2.43 1.17 238 4.94 36.55 Logger#add >> 6.57 3.23 0.80 238 3.37 5.86 >> > MonitorMixin.mon_exit > >> 5.23 3.86 0.64 238 2.68 4.19 Logger:: >> Formatter#format_datetime >> 4.92 4.46 0.60 238 2.52 19.33 MonitorMixin. >> mon_synchronize >> 4.37 5.00 0.53 274 1.95 1.95 IO#write >> 4.12 5.50 0.50 238 2.11 5.62 Logger:: >> LogDevice#check_shift_log >> 3.36 5.91 0.41 238 1.72 3.01 >> > MonitorMixin.mon_enter > >> 3.23 6.30 0.39 497 0.79 1.52 Class#new >> 3.08 6.68 0.38 238 1.58 1.65 >> > Logger::Formatter#msg2str > >> 2.33 6.96 0.28 238 1.19 1.62 >> > Logger#format_severity > >> 2.33 7.24 0.28 238 1.19 37.75 Logger#info >> 2.21 7.51 0.27 238 1.13 7.65 >> > Logger::Formatter#call > >> 2.18 7.78 0.27 238 1.12 1.12 >> > File::Stat#initialize > >> 2.08 8.03 0.25 17 14.94 658.12 FileFormat:: >> WavFile#getInfo >> 1.71 8.24 0.21 238 0.88 1.00 >> > MonitorMixin.mon_acquire > >> 1.70 8.45 0.21 87 2.38 4.87 FileFormat:: >> WavFile#dataPos >> 1.62 8.65 0.20 177 1.12 10.50 FileFormat:: >> WavFile#readBigNum >> 1.51 8.83 0.18 478 0.38 0.55 String#% >> 1.44 9.01 0.18 238 0.74 8.39 >> > Logger#format_message > >> 1.40 9.18 0.17 476 0.36 0.36 NilClass#nil? >> 1.37 9.35 0.17 238 0.70 1.08 >> > MonitorMixin.mon_release > >> 1.32 9.51 0.16 238 0.68 0.68 Time#strftime >> 1.31 9.67 0.16 298 0.54 0.54 IO#pos= >> 1.23 9.82 0.15 915 0.16 0.16 >> > FileFormat::WavFile#file > >> 1.19 9.96 0.15 238 0.61 19.94 >> > Logger::LogDevice#write > >> 1.10 10.10 0.13 952 0.14 0.14 >> > ##critical= > >> 1.00 10.22 0.12 238 0.51 0.80 MonitorMixin. >> mon_check_owner >> 0.91 10.33 0.11 530 0.21 0.21 IO#getc >> 0.85 10.43 0.10 238 0.43 0.43 Kernel.is_a? >> 0.85 10.54 0.10 1060 0.10 0.10 Fixnum#* >> 0.83 10.64 0.10 239 0.42 0.42 Array#[] >> 0.81 10.74 0.10 476 0.21 0.21 Fixnum#> >> 0.75 10.83 0.09 476 0.19 0.19 Array#shift >> 0.72 10.91 0.09 965 0.09 0.09 Fixnum#+ >> 0.71 11.00 0.09 8 10.75 1494.63 Array#each >> 0.71 11.09 0.09 34 2.53 2.53 IO#read >> 0.66 11.17 0.08 238 0.34 2.50 File#stat >> 0.66 11.25 0.08 238 0.34 0.34 Time#usec >> 0.64 11.33 0.08 238 0.33 0.33 NilClass#to_s >> 0.62 11.40 0.08 238 0.32 0.32 >> > Kernel.respond_to? > >> 0.61 11.47 0.07 35 2.11 11.74 FileFormat:: >> WavFile#audioFormat >> 0.57 11.54 0.07 344 0.20 0.21 Fixnum#== >> 0.51 11.61 0.06 476 0.13 0.13 >> > ##current > >> 0.40 11.65 0.05 238 0.21 0.21 Fixnum#< >> 0.33 11.69 0.04 325 0.12 0.12 Kernel.== >> 0.32 11.73 0.04 17 2.29 5.71 >> > FileFormat::WavFile#exist? > >> 0.25 11.76 0.03 1 31.00 31.00 File#initialize >> 0.25 11.79 0.03 222 0.14 0.14 Fixnum#to_s >> 0.24 11.82 0.03 85 0.34 0.34 FileFormat:: >> WavFile#fileDir >> 0.21 11.85 0.02 238 0.11 0.11 >> > Kernel.block_given? > >> 0.20 11.87 0.02 240 0.10 0.10 Time#initialize >> 0.19 11.90 0.02 17 1.35 1.71 FileFormat:: >> WavFile#readBytes >> 0.19 11.92 0.02 238 0.10 0.10 >> > ##pass > >> 0.17 11.94 0.02 17 1.24 16.71 FileFormat:: >> WavFile#extraParamSize >> 0.15 11.96 0.02 17 1.06 1.94 FileFormat:: >> WavFile#openFile >> 0.15 11.98 0.02 238 0.08 0.08 Module#=== >> 0.14 11.99 0.02 355 0.05 0.05 Fixnum#- >> 0.13 12.01 0.02 34 0.47 23.35 FileFormat:: >> WavFile#subChunk2Size >> 0.13 12.02 0.02 87 0.18 0.18 IO#readline >> 0.10 12.04 0.01 18 0.67 16.67 FileFormat:: >> WavFile#bitPerSample >> 0.10 12.05 0.01 238 0.05 0.05 File::Stat#size >> 0.09 12.06 0.01 238 0.05 0.05 Kernel.nil? >> 0.08 12.07 0.01 1 10.00 801.00 FileFormat:: >> FileConcat#concatFiles >> 0.08 12.08 0.01 17 0.59 0.59 FileFormat:: >> WavFile#initialize >> 0.07 12.09 0.01 17 0.53 0.53 >> > ##open > >> 0.07 12.10 0.01 34 0.26 0.38 FileFormat:: >> WavFile#fileSize >> 0.07 12.11 0.01 18 0.44 5.67 FileFormat:: >> WavFile#sampleRate >> 0.07 12.11 0.01 87 0.09 0.09 String#index >> 0.05 12.12 0.01 9 0.67 4.78 FileFormat:: >> FileConcat#writeData >> 0.05 12.12 0.01 17 0.35 0.35 FileTest.exist? >> 0.04 12.13 0.01 2 2.50 8.00 Integer#downto >> 0.04 12.14 0.01 18 0.28 6.17 FileFormat:: >> WavFile#subChunk1Size >> 0.04 12.14 0.01 18 0.28 4.67 FileFormat:: >> WavFile#blockAlign >> 0.04 12.15 0.00 17 0.29 0.71 FileFormat:: >> WavFile#chunkSize >> 0.04 12.15 0.00 18 0.28 12.22 FileFormat:: >> WavFile#byteRate >> 0.03 12.15 0.00 34 0.12 0.12 FileTest.size >> 0.03 12.16 0.00 44 0.09 0.09 IO#putc >> 0.03 12.16 0.00 18 0.22 0.22 IO#to_io >> 0.02 12.17 0.00 17 0.18 5.82 FileFormat:: >> WavFile#extraParams >> 0.02 12.17 0.00 2 1.50 3.50 Logger:: >> LogDevice#create_logfile >> 0.02 12.17 0.00 20 0.15 0.15 IO#close >> 0.02 12.17 0.00 17 0.12 0.12 Array#<< >> 0.02 12.18 0.00 8 0.25 0.25 >> > ##rename > >> 0.02 12.18 0.00 28 0.07 0.07 Fixnum#<< >> 0.02 12.18 0.00 56 0.04 0.04 Fixnum#>> >> 0.02 12.18 0.00 18 0.11 8.94 FileFormat:: >> WavFile#numChannels >> 0.02 12.18 0.00 51 0.04 0.04 IO#eof >> 0.01 12.18 0.00 2 0.50 2.00 Logger:: >> LogDevice#add_log_header >> 0.01 12.18 0.00 2 0.50 0.50 Time#to_s >> 0.00 12.18 0.00 2 0.00 0.00 IO#sync= >> 0.00 12.18 0.00 2 0.00 12.50 Logger:: >> LogDevice#shift_log_age >> 0.00 12.18 0.00 6 0.00 0.00 >> > ##exist? > >> 0.00 12.18 0.00 1 0.00 0.00 Array#length >> 0.00 12.18 0.00 2 0.00 0.00 Kernel.open >> 0.00 12.18 0.00 1 0.00 31.00 FileFormat:: >> FileConcat#initialize >> 0.00 12.18 0.00 17 0.00 0.00 Array#to_s >> 0.00 12.18 0.00 1 0.00 209.00 FileFormat:: >> FileConcat#concat_data_block >> 0.00 12.18 0.00 4 0.00 0.00 Fixnum#| >> 0.00 12.18 0.00 4 0.00 1.00 FileFormat:: >> FileConcat#writeBytes >> 0.00 12.19 0.00 1 0.00 12187.00 #toplevel >> >> This performance of JRuby is rather bad. Reasons may come from: >> 1. JRuby is in nature very slow. We can not do anything to this >> 2. JRuby's startup time is longer than that of Ruby. I wonder this >> situation would be improved if we have had on in-memory JVM >> >> >> Peter K Chan wrote: >> Not anymore, Nate. :) >> >> JRuby WAS slow six months ago, but it has come a long way. Check this >> > out: > >> > http://headius.blogspot.com/2007/04/paving-road-to-jruby-10-performance. > html > >> Summary: In interpretive mode, JRuby is no more than 2x slower, and >> that's including JVM startup and lack of hotspot warm up. In >> unoptimized compiled mode, JRuby often beats C Ruby. I have been using >> JRuby in my project, and I haven't had any performance complaints >> since 2 months ago. >> >> Peter >> ________________________________________ >> From: chicagogroup-members-list-bounces at rubyforge.org [mailto: >> chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate >> > Kirby > >> Sent: Tuesday, May 29, 2007 2:23 AM >> To: Chirb discussion list >> Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t >> >> Peter, >> >> JRuby is slow. Try RJB (http://rjb.rubyforge.org/) >> >> Nate >> >> Peter K Chan wrote: >> Sure! I will be up for some Uger-hacking/feedback-taking (I also need >> > to > >> apply Colin's patch from a while ago and push it out). >> >> Hmm...maybe I should think of a lightning talk on JRuby or something. >> >> Peter >> >> -----Original Message----- >> From: chicagogroup-members-list-bounces at rubyforge.org >> [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of >> Evan Farrar >> Sent: Monday, May 28, 2007 5:51 PM >> To: Chirb discussion list >> Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t >> >> Woohoo Lightning talks! I will definitely come with something. I also >> would like to call together a uger hacksession if Peter Chang is >> around for the meeting. >> >> On 5/28/07, Josh Cronemeyer wrote: >> >> Ok, nobody signed up for the talk and we are a week away from the next >> CHIRB. Soooo, unless anyone objects I think we should have another >> "lightning talk / code pit" session like the one last december. If >> >> you can >> >> prepare something that you can get through in 10 minutes or so, please >> >> do. >> >> Alternatively you can put out a request for a talk on a certain topic >> >> and >> >> perhaps that will inspire somebody. I'm mulling over a topic just to >> >> force >> >> myself to learn something new (Why's camping framework). But I make >> >> no >> >> promises :) Let's have fun with this and take advantage of the chance >> >> for >> >> all of us to talk. No pressure!!!! >> >> http://chirb.org/event/show/18 >> >> Josh Cronemeyer >> _______________________________________________ >> ChicagoGroup-Members-List at rubyforge.org >> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list >> >> >> _______________________________________________ >> ChicagoGroup-Members-List at rubyforge.org >> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list >> _______________________________________________ >> ChicagoGroup-Members-List at rubyforge.org >> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list >> >> >> >> _______________________________________________ >> ChicagoGroup-Members-List at rubyforge.org >> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list >> >> >> _______________________________________________ >> ChicagoGroup-Members-List at rubyforge.org >> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list >> >> _______________________________________________ >> ChicagoGroup-Members-List at rubyforge.org >> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list >> >> >> >> _______________________________________________ >> ChicagoGroup-Members-List at rubyforge.org >> http://rubyforge.org/mailman/listinfo/chicagogroup-members-list >> >> >> >> > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070616/501daa4a/attachment-0001.html From peter at oaktop.com Sun Jun 17 14:01:07 2007 From: peter at oaktop.com (Peter K Chan) Date: Sun, 17 Jun 2007 14:01:07 -0400 Subject: [Chirb] JRuby performance In-Reply-To: <4673D78A.50001@yahoo.com> References: <465BF078.8050808@yahoo.com> <465CC5FD.7030505@yahoo.com> <465D85AD.3010700@yahoo.com> <4673D78A.50001@yahoo.com> Message-ID: Nate, Thanks for reporting back with your findings. For the past few months I have heard reports about how Java is approaching or even exceeding C speed on certain algorithmic implementation. This could explain why writing the Tower of Hanoi is so much faster in Java then Ruby - the algorithm is probably well-optimized by the JVM just-in-time compiler, and you are essentially comparing purely-interpreted Ruby speed with native C speed. Also, since JRuby runs inside the JVM, that would explain why it is faster than RJB. I imagine that RJB is using Java Native Interface to call Java code, which can be slow. Can you post (or send me privately) the code that you used to benchmark? Reading from your email, it sounds like you did a bunch of test, but it wasn't very clear exactly what you tested for. (Hanoi in Java vs. Hanoi in C Ruby? Hanoi in C Ruby vs. Hanoi in JRuby? RJB vs. JRuby in invoking Java code?) I don't think I have any more comments to add to this, but I wouldn't mind taking a look at the code. Thanks, Peter From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate Kirby Sent: Saturday, June 16, 2007 7:29 AM To: Chirb discussion list Subject: Re: [Chirb] JRuby performance Peter, I don't like eating crow, but it is better than starving.? The current results are (the I in this is not form me but a colleague) [Summation: Performance for CPU indicates JRuby is the? way to go] ############################################### Here are the results: 1. Java is much faster than Ruby. Implementing the Hanoi algorithm in Java, either calling from JRuby or through RJB gains the hundreds of times of performance boost. At first I let the number of disks be 28, the same as last time I sent you, but this time only takes a few seconds. ------------------------------------------------------------------------------------ clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh Loaded suite test/functional/test_controller_test Started Number of disks: 28 Start Time: 1181985788.69547 Finish Time: 1181985796.42535 Time used: 7.72987794876099 seconds . Finished in 7.808512 seconds. 1 tests, 0 assertions, 0 failures, 0 errors ---------------------------------------------------------------------------- clive at epiphany:~/Desktop/performance$ ./jruby.sh Number of disks: 28 Start Time: 1181984655.81 Finish Time: 1181984659.713 Time used: 3.9030001163482666 seconds --------------------------------------------------------------------------------- 2. Since both only took a few seconds, I increased the number of disks to gain more accurate results, and found that calling Java code from JRuby is faster than calling through RJB: ------------------------------------------------------------------------------- clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh Loaded suite test/functional/test_controller_test Started Number of disks: 35 Start Time: 1181985899.15607 Finish Time: 1181986895.74254 Time used: 996.586473941803 seconds . Finished in 996.662218 seconds. ------------------------------------------------------------------------------- clive at epiphany:~/Desktop/performance$ ./jruby.sh Number of disks: 35 Start Time: 1181988594.084 Finish Time: 1181989376.494 Time used: 782.4099998474121 seconds ------------------------------------------------------------------------------------ A few notes: 1. I don't know how to use RJB in ruby without rails, so I created a rails project and wrote a functional test to host those code. The rjb.sh in the zip file is what I used to run the test. I used Java server VM to run the Java code. I wonder if there are more things to do to tune the performance of RJB. 2. For JRuby, I used all performance tuning methods I used last time, plus this time I used Java server VM. This can be seen in jruby.sh 3. hanoi.zip is the Java code I used. I have trouble in passing arguments of primitive types to Java, both in rjb and jruby, so I overloaded the method with arguments of classes. But in terms of performance comparison, I don't think that matters. ############################################## Needless to say we are investigation JRuby seriously now.? If you want the source for these tests I can provide it. Blessing, Nate Peter K Chan wrote: Nate, Thanks for getting back to me. I haven't seen the source for your benchmark, but I imagine that it may be doing some specific processing that JRuby is slow at (i.e. looking at the method names, it seems to be doing quite a bit of byte shuffling?). Also, just a guess, but the 8x difference worsening to 14x times may be due to JVM startup cost (a real possibility; once you step into single digit second run time). In any case, here is a link which explains how to tune JRuby for performance, including how to disable Object Space and turn on compiler: http://www.headius.com/jrubywiki/index.php/Performance_Tuning Just to put things in context: JRuby shines when you are doing integration with Java and long running server processes. One time scripts may still be a sore point for the foreseeable future, simply because of the JVM start-up and warm-up cost. Peter -----Original Message----- From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate Kirby Sent: Wednesday, May 30, 2007 9:10 AM To: Chirb discussion list Subject: Re: [Chirb] JRuby performance Peter, This is the reponse I got: ************* The JVM on my Ubuntu machine is Sun's: clive at epiphany:~$ java -version java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) And I use the latest version of JRuby. I ran that piece of code with profiling again on my machine, which is very old one, C Ruby took 2.72 sec, JRuby took 22.78 sec. 8.375 times difference. Then I changed the code, took out profiler, and printed out the start time and finish time only, C Ruby took 0.27586 sec, JRuby took 4.074 sec: 14.768360763 times difference. The attachment is the raw data. I did not: -disable object space (I did some research, but have no idea of how to do that. The hotspot server seemed to have some option about size of object space, but I don't think it allows us to set the size to 0) -turn on the JRuby AOT or JIT compiler ( I have no idea of what that is) It seems that the performance under default setting is still bad. ************** Blessings, Nate Peter K Chan wrote: Sure, Nate. I do concede that JRuby is not yet a Ruby drop in replacement, at least not for running small scripts. It takes only 5 minutes to tweak the performance, but it is still 5 minutes more than C Ruby. Where JRuby really shines is in Java integration and scalability (e.g. running multiple rails instances within a single JVM, connecting to a JDBC database). I would be very interested in seeing what kind of performance you get for your evaluation. Peter ________________________________________ From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate Kirby Sent: Tuesday, May 29, 2007 7:32 PM To: Chirb discussion list Subject: Re: [Chirb] JRuby performance Peter, I actually had someone else do it. I will forward your suggestions along to them. I have had the impression in the past that individual vendors VMs were often faster than Suns for their platform. That is possibly in error, but in the late 90's it was not. Thanks, Nate Peter K Chan wrote: Nate, Josh has already brought up most of what I was going to reply to you, but let me just highlight these factors, which may explain your performance result: - Are you using a modern JVM, such as Sun 1.6.0, with hotspot/JIT compilation? - Did you disable object space? (Makes a huge 20% - 40% difference, I disable it in all my apps) - Did you pull the latest trunk or at least RC version of JRuby? - Did you turn on the JRuby AOT or JIT compiler? - I think that JRuby's set_trace_func is slow; therefore, if you use profile.rb, you may be incurring large profiling cost (actually, set_trace_func isn't working in current JRuby compiler, so you must have been running JRuby in pure interpretive mode). Also, keep in mind that the benchmark result I linked to include JVM startup time. If you consider that the JVM takes a few seconds to fully warm up, and most benchmark finishes in a few seconds, JRuby's result is even more impressive. Don't take my word for it. Run your benchmark with the right settings, and you can see for yourself. :) Peter ________________________________________ From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Josh Cronemeyer Sent: Tuesday, May 29, 2007 11:11 AM To: Chirb discussion list Subject: [Chirb] JRuby performance discussion moved from this thread: Re: [Chirb] time to rsvp for the mystery meeting! W00t Nate, I've heard alot of good stuff about jruby performance, not from just peter. [programmer at Mark ~]$ java --version java version "1.4.2" gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) I think you should run your tests with a real JVM (like sun's implementation). You are using gij which is a java interpretor. GIJ is a part of the GCJ project. GCJ is a very different beast than sun's implementation. The idea behind GCJ is that java is compiled down to your specific platform's machine code. So they bypass the jvm all together. This sounds like it would be faster, but it really isn't for many things because sun's just in time compilation can actually compile the same code in different ways depending on context in order to optimize execution. I'm not sure if Jruby uses runtime code loading or generation (i wouldn't be surprised though). If that is the case GCJ is SUPER slow for those types of operations because that is when the gij interpreter kicks in. The interpreter is realizing no benefits from optimization or compilation. The short of it: I wouldn't call my tests definitive until I was using sun's jvm. Josh Cronemeyer chicagogroup-members-list-bounces at rubyforge.org wrote on 05/29/2007 04:20:56 AM: Peter, I can take your word for it....or I can check the performance stats we just did a few weeks ago JRuby was 10x slower than ruby at the command line on a Fedora box. Nate STATS [programmer at Mark ~]$ java --version java version "1.4.2" gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I did not change the default JVM. I used the Ruby project concatenating wav files and profiler to see the performance data. This is the result: Ruby: % cumulative self self total time seconds seconds calls ms/call ms/call name 10.24 0.13 0.13 238 0.55 1.13 MonitorMixin.mon_exit 7.09 0.22 0.09 238 0.38 2.27 MonitorMixin.synchronize 6.30 0.30 0.08 238 0.34 3.57 Logger#add 5.51 0.37 0.07 238 0.29 0.34 Logger:: Formatter#format_datetime 4.72 0.43 0.06 17 3.53 68.82 FileFormat:: WavFile#getInfo 4.72 0.49 0.06 203 0.30 0.69 Integer#times 3.94 0.54 0.05 238 0.21 0.42 Logger:: LogDevice#check_shift_log 3.15 0.58 0.04 238 0.17 0.25 MonitorMixin.mon_release 3.15 0.62 0.04 238 0.17 0.34 MonitorMixin.mon_enter 2.36 0.65 0.03 256 0.12 0.12 String#+ 2.36 0.68 0.03 87 0.34 0.57 FileFormat:: WavFile#dataPos 2.36 0.71 0.03 177 0.17 0.85 FileFormat:: WavFile#readBigNum 2.36 0.74 0.03 530 0.06 0.06 IO#getc 2.36 0.77 0.03 8 3.75 155.00 Array#each 2.36 0.80 0.03 476 0.06 0.06 Thread#current 2.36 0.83 0.03 238 0.13 0.13 Logger#format_severity 2.36 0.86 0.03 238 0.13 0.21 MonitorMixin. mon_check_owner 2.36 0.89 0.03 952 0.03 0.03 Thread#critical= 2.36 0.92 0.03 238 0.13 0.55 Logger::Formatter#call 1.57 0.94 0.02 476 0.04 0.04 Array#shift 1.57 0.96 0.02 1060 0.02 0.02 Fixnum#* 1.57 0.98 0.02 238 0.08 0.08 Module#=== 1.57 1.00 0.02 238 0.08 0.08 IO#stat 1.57 1.02 0.02 87 0.23 0.23 IO#readline 1.57 1.04 0.02 476 0.04 0.04 Fixnum#> 1.57 1.06 0.02 965 0.02 0.02 Fixnum#+ 0.79 1.07 0.01 17 0.59 2.94 FileFormat:: WavFile#extraParams 0.79 1.08 0.01 238 0.04 0.04 Kernel.nil? 0.79 1.09 0.01 240 0.04 0.04 Time#initialize 0.79 1.10 0.01 44 0.23 0.23 IO#putc 0.79 1.11 0.01 34 0.29 0.29 FileFormat:: WavFile#fileSize 0.79 1.12 0.01 238 0.04 0.59 Logger#format_message 0.79 1.13 0.01 34 0.29 0.29 IO#read 0.79 1.14 0.01 17 0.59 0.59 FileFormat:: WavFile#readBytes 0.79 1.15 0.01 238 0.04 0.04 Time#usec 0.79 1.16 0.01 238 0.04 0.04 Kernel.block_given? 0.79 1.17 0.01 238 0.04 2.31 Logger::LogDevice#write 0.79 1.18 0.01 18 0.56 0.56 FileFormat:: WavFile#bitPerSample 0.79 1.19 0.01 34 0.29 1.47 FileFormat:: WavFile#subChunk2Size 0.79 1.20 0.01 238 0.04 0.13 MonitorMixin.mon_acquire 0.79 1.21 0.01 238 0.04 0.04 Fixnum#< 0.79 1.22 0.01 238 0.04 3.61 Logger#info 0.79 1.23 0.01 18 0.56 1.67 FileFormat:: WavFile#sampleRate 0.79 1.24 0.01 325 0.03 0.03 Kernel.== 0.79 1.25 0.01 238 0.04 0.04 File::Stat#size 0.79 1.26 0.01 240 0.04 0.08 Time#now 0.79 1.27 0.01 344 0.03 0.03 Fixnum#== 0.00 1.27 0.00 2 0.00 0.00 IO#sync= 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: WavFile#byteRate 0.00 1.27 0.00 18 0.00 0.00 Class#new 0.00 1.27 0.00 17 0.00 0.00 Array#to_s 0.00 1.27 0.00 1 0.00 0.00 FileFormat:: FileConcat#initialize 0.00 1.27 0.00 18 0.00 0.00 IO#to_io 0.00 1.27 0.00 35 0.00 0.00 FileFormat:: WavFile#audioFormat 0.00 1.27 0.00 238 0.00 0.08 Logger::Formatter#msg2str 0.00 1.27 0.00 238 0.00 0.00 String#[] 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: WavFile#openFile 0.00 1.27 0.00 28 0.00 0.00 Fixnum#<< 0.00 1.27 0.00 56 0.00 0.00 Fixnum#>> 0.00 1.27 0.00 2 0.00 0.00 Logger:: LogDevice#create_logfile 0.00 1.27 0.00 298 0.00 0.00 IO#pos= 0.00 1.27 0.00 17 0.00 0.00 File#exist? 0.00 1.27 0.00 238 0.00 0.00 Thread#pass 0.00 1.27 0.00 238 0.00 0.00 NilClass#to_s 0.00 1.27 0.00 17 0.00 0.00 Array#<< 0.00 1.27 0.00 51 0.00 0.00 IO#eof? 0.00 1.27 0.00 9 0.00 2.22 FileFormat:: FileConcat#writeData 0.00 1.27 0.00 2 0.00 0.00 Time#to_s 0.00 1.27 0.00 17 0.00 0.00 FileFormat::WavFile#exist? 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: WavFile#chunkSize 0.00 1.27 0.00 238 0.00 0.00 Kernel.respond_to? 0.00 1.27 0.00 1 0.00 0.00 IO#new 0.00 1.27 0.00 238 0.00 0.00 Time#strftime 0.00 1.27 0.00 4 0.00 0.00 Fixnum#| 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: WavFile#blockAlign 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: WavFile#extraParamSize 0.00 1.27 0.00 6 0.00 0.00 FileTest.exist? 0.00 1.27 0.00 17 0.00 0.00 IO#open 0.00 1.27 0.00 355 0.00 0.00 Fixnum#- 0.00 1.27 0.00 239 0.00 0.00 Array#[] 0.00 1.27 0.00 18 0.00 1.67 FileFormat:: WavFile#numChannels 0.00 1.27 0.00 1 0.00 0.00 Array#size 0.00 1.27 0.00 20 0.00 0.00 IO#close 0.00 1.27 0.00 8 0.00 0.00 File#rename 0.00 1.27 0.00 87 0.00 0.00 String#index 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: WavFile#initialize 0.00 1.27 0.00 1 0.00 90.00 FileFormat:: FileConcat#concatFiles 0.00 1.27 0.00 2 0.00 0.00 Kernel.open 0.00 1.27 0.00 2 0.00 0.00 Integer#downto 0.00 1.27 0.00 4 0.00 0.00 FileFormat:: FileConcat#writeBytes 0.00 1.27 0.00 1 0.00 30.00 FileFormat:: FileConcat#concat_data_block 0.00 1.27 0.00 476 0.00 0.00 NilClass#nil? 0.00 1.27 0.00 20 0.00 0.00 File#initialize 0.00 1.27 0.00 478 0.00 0.00 String#% 0.00 1.27 0.00 2 0.00 0.00 Logger:: LogDevice#add_log_header 0.00 1.27 0.00 18 0.00 2.78 FileFormat:: WavFile#subChunk1Size 0.00 1.27 0.00 2 0.00 0.00 Logger:: LogDevice#shift_log_age 0.00 1.27 0.00 318 0.00 0.00 IO#write 0.00 1.27 0.00 238 0.00 0.00 String#<< 0.00 1.27 0.00 238 0.00 0.00 Kernel.is_a? 0.00 1.27 0.00 222 0.00 0.00 Fixnum#to_s 0.00 1.27 0.00 34 0.00 0.00 File#size 0.00 1.27 0.00 1 0.00 1270.00 #toplevel JRuby: % cumulative self self total time seconds seconds calls ms/call ms/call name 10.27 1.25 1.25 203 6.17 7.84 Integer#times 9.64 2.43 1.17 238 4.94 36.55 Logger#add 6.57 3.23 0.80 238 3.37 5.86 MonitorMixin.mon_exit 5.23 3.86 0.64 238 2.68 4.19 Logger:: Formatter#format_datetime 4.92 4.46 0.60 238 2.52 19.33 MonitorMixin. mon_synchronize 4.37 5.00 0.53 274 1.95 1.95 IO#write 4.12 5.50 0.50 238 2.11 5.62 Logger:: LogDevice#check_shift_log 3.36 5.91 0.41 238 1.72 3.01 MonitorMixin.mon_enter 3.23 6.30 0.39 497 0.79 1.52 Class#new 3.08 6.68 0.38 238 1.58 1.65 Logger::Formatter#msg2str 2.33 6.96 0.28 238 1.19 1.62 Logger#format_severity 2.33 7.24 0.28 238 1.19 37.75 Logger#info 2.21 7.51 0.27 238 1.13 7.65 Logger::Formatter#call 2.18 7.78 0.27 238 1.12 1.12 File::Stat#initialize 2.08 8.03 0.25 17 14.94 658.12 FileFormat:: WavFile#getInfo 1.71 8.24 0.21 238 0.88 1.00 MonitorMixin.mon_acquire 1.70 8.45 0.21 87 2.38 4.87 FileFormat:: WavFile#dataPos 1.62 8.65 0.20 177 1.12 10.50 FileFormat:: WavFile#readBigNum 1.51 8.83 0.18 478 0.38 0.55 String#% 1.44 9.01 0.18 238 0.74 8.39 Logger#format_message 1.40 9.18 0.17 476 0.36 0.36 NilClass#nil? 1.37 9.35 0.17 238 0.70 1.08 MonitorMixin.mon_release 1.32 9.51 0.16 238 0.68 0.68 Time#strftime 1.31 9.67 0.16 298 0.54 0.54 IO#pos= 1.23 9.82 0.15 915 0.16 0.16 FileFormat::WavFile#file 1.19 9.96 0.15 238 0.61 19.94 Logger::LogDevice#write 1.10 10.10 0.13 952 0.14 0.14 ##critical= 1.00 10.22 0.12 238 0.51 0.80 MonitorMixin. mon_check_owner 0.91 10.33 0.11 530 0.21 0.21 IO#getc 0.85 10.43 0.10 238 0.43 0.43 Kernel.is_a? 0.85 10.54 0.10 1060 0.10 0.10 Fixnum#* 0.83 10.64 0.10 239 0.42 0.42 Array#[] 0.81 10.74 0.10 476 0.21 0.21 Fixnum#> 0.75 10.83 0.09 476 0.19 0.19 Array#shift 0.72 10.91 0.09 965 0.09 0.09 Fixnum#+ 0.71 11.00 0.09 8 10.75 1494.63 Array#each 0.71 11.09 0.09 34 2.53 2.53 IO#read 0.66 11.17 0.08 238 0.34 2.50 File#stat 0.66 11.25 0.08 238 0.34 0.34 Time#usec 0.64 11.33 0.08 238 0.33 0.33 NilClass#to_s 0.62 11.40 0.08 238 0.32 0.32 Kernel.respond_to? 0.61 11.47 0.07 35 2.11 11.74 FileFormat:: WavFile#audioFormat 0.57 11.54 0.07 344 0.20 0.21 Fixnum#== 0.51 11.61 0.06 476 0.13 0.13 ##current 0.40 11.65 0.05 238 0.21 0.21 Fixnum#< 0.33 11.69 0.04 325 0.12 0.12 Kernel.== 0.32 11.73 0.04 17 2.29 5.71 FileFormat::WavFile#exist? 0.25 11.76 0.03 1 31.00 31.00 File#initialize 0.25 11.79 0.03 222 0.14 0.14 Fixnum#to_s 0.24 11.82 0.03 85 0.34 0.34 FileFormat:: WavFile#fileDir 0.21 11.85 0.02 238 0.11 0.11 Kernel.block_given? 0.20 11.87 0.02 240 0.10 0.10 Time#initialize 0.19 11.90 0.02 17 1.35 1.71 FileFormat:: WavFile#readBytes 0.19 11.92 0.02 238 0.10 0.10 ##pass 0.17 11.94 0.02 17 1.24 16.71 FileFormat:: WavFile#extraParamSize 0.15 11.96 0.02 17 1.06 1.94 FileFormat:: WavFile#openFile 0.15 11.98 0.02 238 0.08 0.08 Module#=== 0.14 11.99 0.02 355 0.05 0.05 Fixnum#- 0.13 12.01 0.02 34 0.47 23.35 FileFormat:: WavFile#subChunk2Size 0.13 12.02 0.02 87 0.18 0.18 IO#readline 0.10 12.04 0.01 18 0.67 16.67 FileFormat:: WavFile#bitPerSample 0.10 12.05 0.01 238 0.05 0.05 File::Stat#size 0.09 12.06 0.01 238 0.05 0.05 Kernel.nil? 0.08 12.07 0.01 1 10.00 801.00 FileFormat:: FileConcat#concatFiles 0.08 12.08 0.01 17 0.59 0.59 FileFormat:: WavFile#initialize 0.07 12.09 0.01 17 0.53 0.53 ##open 0.07 12.10 0.01 34 0.26 0.38 FileFormat:: WavFile#fileSize 0.07 12.11 0.01 18 0.44 5.67 FileFormat:: WavFile#sampleRate 0.07 12.11 0.01 87 0.09 0.09 String#index 0.05 12.12 0.01 9 0.67 4.78 FileFormat:: FileConcat#writeData 0.05 12.12 0.01 17 0.35 0.35 FileTest.exist? 0.04 12.13 0.01 2 2.50 8.00 Integer#downto 0.04 12.14 0.01 18 0.28 6.17 FileFormat:: WavFile#subChunk1Size 0.04 12.14 0.01 18 0.28 4.67 FileFormat:: WavFile#blockAlign 0.04 12.15 0.00 17 0.29 0.71 FileFormat:: WavFile#chunkSize 0.04 12.15 0.00 18 0.28 12.22 FileFormat:: WavFile#byteRate 0.03 12.15 0.00 34 0.12 0.12 FileTest.size 0.03 12.16 0.00 44 0.09 0.09 IO#putc 0.03 12.16 0.00 18 0.22 0.22 IO#to_io 0.02 12.17 0.00 17 0.18 5.82 FileFormat:: WavFile#extraParams 0.02 12.17 0.00 2 1.50 3.50 Logger:: LogDevice#create_logfile 0.02 12.17 0.00 20 0.15 0.15 IO#close 0.02 12.17 0.00 17 0.12 0.12 Array#<< 0.02 12.18 0.00 8 0.25 0.25 ##rename 0.02 12.18 0.00 28 0.07 0.07 Fixnum#<< 0.02 12.18 0.00 56 0.04 0.04 Fixnum#>> 0.02 12.18 0.00 18 0.11 8.94 FileFormat:: WavFile#numChannels 0.02 12.18 0.00 51 0.04 0.04 IO#eof 0.01 12.18 0.00 2 0.50 2.00 Logger:: LogDevice#add_log_header 0.01 12.18 0.00 2 0.50 0.50 Time#to_s 0.00 12.18 0.00 2 0.00 0.00 IO#sync= 0.00 12.18 0.00 2 0.00 12.50 Logger:: LogDevice#shift_log_age 0.00 12.18 0.00 6 0.00 0.00 ##exist? 0.00 12.18 0.00 1 0.00 0.00 Array#length 0.00 12.18 0.00 2 0.00 0.00 Kernel.open 0.00 12.18 0.00 1 0.00 31.00 FileFormat:: FileConcat#initialize 0.00 12.18 0.00 17 0.00 0.00 Array#to_s 0.00 12.18 0.00 1 0.00 209.00 FileFormat:: FileConcat#concat_data_block 0.00 12.18 0.00 4 0.00 0.00 Fixnum#| 0.00 12.18 0.00 4 0.00 1.00 FileFormat:: FileConcat#writeBytes 0.00 12.19 0.00 1 0.00 12187.00 #toplevel This performance of JRuby is rather bad. Reasons may come from: 1. JRuby is in nature very slow. We can not do anything to this 2. JRuby's startup time is longer than that of Ruby. I wonder this situation would be improved if we have had on in-memory JVM Peter K Chan wrote: Not anymore, Nate. :) JRuby WAS slow six months ago, but it has come a long way. Check this out: http://headius.blogspot.com/2007/04/paving-road-to-jruby-10-performance. html Summary: In interpretive mode, JRuby is no more than 2x slower, and that's including JVM startup and lack of hotspot warm up. In unoptimized compiled mode, JRuby often beats C Ruby. I have been using JRuby in my project, and I haven't had any performance complaints since 2 months ago. Peter ________________________________________ From: chicagogroup-members-list-bounces at rubyforge.org [mailto: chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate Kirby Sent: Tuesday, May 29, 2007 2:23 AM To: Chirb discussion list Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t Peter, JRuby is slow. Try RJB (http://rjb.rubyforge.org/) Nate Peter K Chan wrote: Sure! I will be up for some Uger-hacking/feedback-taking (I also need to apply Colin's patch from a while ago and push it out). Hmm...maybe I should think of a lightning talk on JRuby or something. Peter -----Original Message----- From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Evan Farrar Sent: Monday, May 28, 2007 5:51 PM To: Chirb discussion list Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t Woohoo Lightning talks! I will definitely come with something. I also would like to call together a uger hacksession if Peter Chang is around for the meeting. On 5/28/07, Josh Cronemeyer wrote: Ok, nobody signed up for the talk and we are a week away from the next CHIRB. Soooo, unless anyone objects I think we should have another "lightning talk / code pit" session like the one last december. If you can prepare something that you can get through in 10 minutes or so, please do. Alternatively you can put out a request for a talk on a certain topic and perhaps that will inspire somebody. I'm mulling over a topic just to force myself to learn something new (Why's camping framework). But I make no promises :) Let's have fun with this and take advantage of the chance for all of us to talk. No pressure!!!! http://chirb.org/event/show/18 Josh Cronemeyer _______________________________________________ ChicagoGroup-Members-List at rubyforge.org http://rubyforge.org/mailman/listinfo/chicagogroup-members-list _______________________________________________ ChicagoGroup-Members-List at rubyforge.org http://rubyforge.org/mailman/listinfo/chicagogroup-members-list _______________________________________________ ChicagoGroup-Members-List at rubyforge.org http://rubyforge.org/mailman/listinfo/chicagogroup-members-list _______________________________________________ ChicagoGroup-Members-List at rubyforge.org http://rubyforge.org/mailman/listinfo/chicagogroup-members-list _______________________________________________ ChicagoGroup-Members-List at rubyforge.org http://rubyforge.org/mailman/listinfo/chicagogroup-members-list _______________________________________________ ChicagoGroup-Members-List at rubyforge.org http://rubyforge.org/mailman/listinfo/chicagogroup-members-list _______________________________________________ ChicagoGroup-Members-List at rubyforge.org http://rubyforge.org/mailman/listinfo/chicagogroup-members-list _______________________________________________ ChicagoGroup-Members-List at rubyforge.org http://rubyforge.org/mailman/listinfo/chicagogroup-members-list From natebkirby at yahoo.com Sun Jun 17 16:34:27 2007 From: natebkirby at yahoo.com (Nate Kirby) Date: Mon, 18 Jun 2007 05:34:27 +0900 Subject: [Chirb] JRuby performance In-Reply-To: References: <465BF078.8050808@yahoo.com> <465CC5FD.7030505@yahoo.com> <465D85AD.3010700@yahoo.com> <4673D78A.50001@yahoo.com> Message-ID: <46759AD3.2060209@yahoo.com> Peter, Peter K Chan wrote: > Nate, > Thanks for reporting back with your findings. For the past few months I have heard reports about how Java is approaching or even exceeding C speed on certain algorithmic implementation. This could explain why writing the Tower of Hanoi is so much faster in Java then Ruby - the algorithm is probably well-optimized by the JVM just-in-time compiler, and you are essentially comparing purely-interpreted Ruby speed with native C speed. > This could be. > Also, since JRuby runs inside the JVM, that would explain why it is faster than RJB. I imagine that RJB is using Java Native Interface to call Java code, which can be slow. > RHB does use JNI - but I have not experienced JNI as "slow" before. > Can you post (or send me privately) the code that you used to benchmark? Reading from your email, it sounds like you did a bunch of test, but it wasn't very clear exactly what you tested for. (Hanoi in Java vs. Hanoi in C Ruby? Hanoi in C Ruby vs. Hanoi in JRuby? RJB vs. JRuby in invoking Java code?) > Attached to this email please find code samples. > I don't think I have any more comments to add to this, but I wouldn't mind taking a look at the code. > Blessings, Nate > Thanks, > > Peter > > From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate Kirby > Sent: Saturday, June 16, 2007 7:29 AM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > I don't like eating crow, but it is better than starving. The current results are (the I in this is not form me but a colleague) > [Summation: Performance for CPU indicates JRuby is the way to go] > > ############################################### > Here are the results: > > 1. Java is much faster than Ruby. Implementing the Hanoi algorithm in > Java, either calling from JRuby or through RJB gains the hundreds of > times of performance boost. At first I let the number of disks be 28, > the same as last time I sent you, but this time only takes a few > seconds. > ------------------------------------------------------------------------------------ > clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh > Loaded suite test/functional/test_controller_test > Started > Number of disks: 28 > Start Time: 1181985788.69547 > Finish Time: 1181985796.42535 > Time used: 7.72987794876099 seconds > . > Finished in 7.808512 seconds. > > 1 tests, 0 assertions, 0 failures, 0 errors > ---------------------------------------------------------------------------- > clive at epiphany:~/Desktop/performance$ ./jruby.sh > Number of disks: 28 > Start Time: 1181984655.81 > Finish Time: 1181984659.713 > Time used: 3.9030001163482666 seconds > --------------------------------------------------------------------------------- > > 2. Since both only took a few seconds, I increased the number of disks > to gain more accurate results, and found that calling Java code from > JRuby is faster than calling through RJB: > ------------------------------------------------------------------------------- > clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh > Loaded suite test/functional/test_controller_test > Started > Number of disks: 35 > Start Time: 1181985899.15607 > Finish Time: 1181986895.74254 > Time used: 996.586473941803 seconds > . > Finished in 996.662218 seconds. > ------------------------------------------------------------------------------- > clive at epiphany:~/Desktop/performance$ ./jruby.sh > Number of disks: 35 > Start Time: 1181988594.084 > Finish Time: 1181989376.494 > Time used: 782.4099998474121 seconds > ------------------------------------------------------------------------------------ > A few notes: > 1. I don't know how to use RJB in ruby without rails, so I created a > rails project and wrote a functional test to host those code. The > rjb.sh in the zip file is what I used to run the test. I used Java > server VM to run the Java code. I wonder if there are more things to > do to tune the performance of RJB. > 2. For JRuby, I used all performance tuning methods I used last time, > plus this time I used Java server VM. This can be seen in jruby.sh > 3. hanoi.zip is the Java code I used. I have trouble in passing > arguments of primitive types to Java, both in rjb and jruby, so I > overloaded the method with arguments of classes. But in terms of > performance comparison, I don't think that matters. > ############################################## > > Needless to say we are investigation JRuby seriously now. If you want the source for these tests I can provide it. > > Blessing, > Nate > > > > > Peter K Chan wrote: > Nate, > Thanks for getting back to me. I haven't seen the source for > your benchmark, but I imagine that it may be doing some specific > processing that JRuby is slow at (i.e. looking at the method names, it > seems to be doing quite a bit of byte shuffling?). > > Also, just a guess, but the 8x difference worsening to 14x times > may be due to JVM startup cost (a real possibility; once you step into > single digit second run time). > > In any case, here is a link which explains how to tune JRuby for > performance, including how to disable Object Space and turn on compiler: > > http://www.headius.com/jrubywiki/index.php/Performance_Tuning > > Just to put things in context: JRuby shines when you are doing > integration with Java and long running server processes. One time > scripts may still be a sore point for the foreseeable future, simply > because of the JVM start-up and warm-up cost. > > Peter > > -----Original Message----- > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > Sent: Wednesday, May 30, 2007 9:10 AM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > This is the reponse I got: > > ************* > The JVM on my Ubuntu machine is Sun's: > > clive at epiphany:~$ java -version > java version "1.6.0" > Java(TM) SE Runtime Environment (build 1.6.0-b105) > Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) > > And I use the latest version of JRuby. I ran that piece of code with > profiling again on my machine, which is very old one, C Ruby took 2.72 > sec, JRuby took 22.78 sec. 8.375 times difference. > Then I changed the code, took out profiler, and printed out the start > time and finish time only, C Ruby took 0.27586 sec, JRuby took 4.074 > sec: 14.768360763 times difference. > > The attachment is the raw data. I did not: > -disable object space (I did some research, but have no idea of how to > do that. The hotspot server seemed to have some option about size of > object space, but I don't think it allows us to set the size to 0) > > -turn on the JRuby AOT or JIT compiler ( I have no idea of what that is) > > It seems that the performance under default setting is still bad. > > ************** > Blessings, > Nate > > Peter K Chan wrote: > > Sure, Nate. > > I do concede that JRuby is not yet a Ruby drop in replacement, at > > least not for running small scripts. It takes only 5 minutes to tweak > the performance, but it is still 5 minutes more than C Ruby. Where JRuby > really shines is in Java integration and scalability (e.g. running > multiple rails instances within a single JVM, connecting to a JDBC > database). > > I would be very interested in seeing what kind of performance you get > > for your evaluation. > > Peter > ________________________________________ > From: chicagogroup-members-list-bounces at rubyforge.org > > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > > Sent: Tuesday, May 29, 2007 7:32 PM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > I actually had someone else do it. I will forward your suggestions > > along to them. I have had the impression in the past that individual > vendors VMs were often faster than Suns for their platform. That is > possibly in error, but in the late 90's it was not. > > Thanks, > Nate > > Peter K Chan wrote: > Nate, > Josh has already brought up most of what I was going to reply to > > you, but let me just highlight these factors, which may explain your > performance result: > > - Are you using a modern JVM, such as Sun 1.6.0, with hotspot/JIT > > compilation? > > - Did you disable object space? (Makes a huge 20% - 40% difference, I > > disable it in all my apps) > > - Did you pull the latest trunk or at least RC version of JRuby? > - Did you turn on the JRuby AOT or JIT compiler? > - I think that JRuby's set_trace_func is slow; therefore, if you use > > profile.rb, you may be incurring large profiling cost (actually, > set_trace_func isn't working in current JRuby compiler, so you must have > been running JRuby in pure interpretive mode). > > > Also, keep in mind that the benchmark result I linked to > > include JVM startup time. If you consider that the JVM takes a few > seconds to fully warm up, and most benchmark finishes in a few seconds, > JRuby's result is even more impressive. > > Don't take my word for it. Run your benchmark with the right > > settings, and you can see for yourself. :) > > Peter > ________________________________________ > From: chicagogroup-members-list-bounces at rubyforge.org > > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Josh Cronemeyer > > Sent: Tuesday, May 29, 2007 11:11 AM > To: Chirb discussion list > Subject: [Chirb] JRuby performance > > > discussion moved from this thread: Re: [Chirb] time to rsvp for the > > mystery meeting! W00t > > Nate, > > I've heard alot of good stuff about jruby performance, not from just > > peter. > > > [programmer at Mark ~]$ java --version > java version "1.4.2" > gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) > > I think you should run your tests with a real JVM (like sun's > > implementation). You are using gij which is a java interpretor. GIJ is > a part of the GCJ project. GCJ is a very different beast than sun's > implementation. The idea behind GCJ is that java is compiled down to > your specific platform's machine code. So they bypass the jvm all > together. This sounds like it would be faster, but it really isn't for > many things because sun's just in time compilation can actually compile > the same code in different ways depending on context in order to > optimize execution. I'm not sure if Jruby uses runtime code loading or > generation (i wouldn't be surprised though). If that is the case GCJ is > SUPER slow for those types of operations because that is when the gij > interpreter kicks in. The interpreter is realizing no benefits from > optimization or compilation. > > The short of it: I wouldn't call my tests definitive until I was using > > sun's jvm. > > Josh Cronemeyer > > chicagogroup-members-list-bounces at rubyforge.org wrote on 05/29/2007 > > 04:20:56 AM: > > > Peter, > > I can take your word for it....or I can check the performance stats we > just did a few weeks ago JRuby was 10x slower than ruby at the command > line on a Fedora box. > > Nate > > STATS > > [programmer at Mark ~]$ java --version > java version "1.4.2" > gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) > > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > > is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > PURPOSE. > > I did not change the default JVM. I used the Ruby project > concatenating wav files and profiler to see the performance data. This > is the result: > Ruby: > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 10.24 0.13 0.13 238 0.55 1.13 > > MonitorMixin.mon_exit > > 7.09 0.22 0.09 238 0.38 2.27 > > MonitorMixin.synchronize > > 6.30 0.30 0.08 238 0.34 3.57 Logger#add > 5.51 0.37 0.07 238 0.29 0.34 Logger:: > Formatter#format_datetime > 4.72 0.43 0.06 17 3.53 68.82 FileFormat:: > WavFile#getInfo > 4.72 0.49 0.06 203 0.30 0.69 Integer#times > 3.94 0.54 0.05 238 0.21 0.42 Logger:: > LogDevice#check_shift_log > 3.15 0.58 0.04 238 0.17 0.25 > > MonitorMixin.mon_release > > 3.15 0.62 0.04 238 0.17 0.34 > > MonitorMixin.mon_enter > > 2.36 0.65 0.03 256 0.12 0.12 String#+ > 2.36 0.68 0.03 87 0.34 0.57 FileFormat:: > WavFile#dataPos > 2.36 0.71 0.03 177 0.17 0.85 FileFormat:: > WavFile#readBigNum > 2.36 0.74 0.03 530 0.06 0.06 IO#getc > 2.36 0.77 0.03 8 3.75 155.00 Array#each > 2.36 0.80 0.03 476 0.06 0.06 Thread#current > 2.36 0.83 0.03 238 0.13 0.13 > > Logger#format_severity > > 2.36 0.86 0.03 238 0.13 0.21 MonitorMixin. > mon_check_owner > 2.36 0.89 0.03 952 0.03 0.03 Thread#critical= > 2.36 0.92 0.03 238 0.13 0.55 > > Logger::Formatter#call > > 1.57 0.94 0.02 476 0.04 0.04 Array#shift > 1.57 0.96 0.02 1060 0.02 0.02 Fixnum#* > 1.57 0.98 0.02 238 0.08 0.08 Module#=== > 1.57 1.00 0.02 238 0.08 0.08 IO#stat > 1.57 1.02 0.02 87 0.23 0.23 IO#readline > 1.57 1.04 0.02 476 0.04 0.04 Fixnum#> > 1.57 1.06 0.02 965 0.02 0.02 Fixnum#+ > 0.79 1.07 0.01 17 0.59 2.94 FileFormat:: > WavFile#extraParams > 0.79 1.08 0.01 238 0.04 0.04 Kernel.nil? > 0.79 1.09 0.01 240 0.04 0.04 Time#initialize > 0.79 1.10 0.01 44 0.23 0.23 IO#putc > 0.79 1.11 0.01 34 0.29 0.29 FileFormat:: > WavFile#fileSize > 0.79 1.12 0.01 238 0.04 0.59 > > Logger#format_message > > 0.79 1.13 0.01 34 0.29 0.29 IO#read > 0.79 1.14 0.01 17 0.59 0.59 FileFormat:: > WavFile#readBytes > 0.79 1.15 0.01 238 0.04 0.04 Time#usec > 0.79 1.16 0.01 238 0.04 0.04 > > Kernel.block_given? > > 0.79 1.17 0.01 238 0.04 2.31 > > Logger::LogDevice#write > > 0.79 1.18 0.01 18 0.56 0.56 FileFormat:: > WavFile#bitPerSample > 0.79 1.19 0.01 34 0.29 1.47 FileFormat:: > WavFile#subChunk2Size > 0.79 1.20 0.01 238 0.04 0.13 > > MonitorMixin.mon_acquire > > 0.79 1.21 0.01 238 0.04 0.04 Fixnum#< > 0.79 1.22 0.01 238 0.04 3.61 Logger#info > 0.79 1.23 0.01 18 0.56 1.67 FileFormat:: > WavFile#sampleRate > 0.79 1.24 0.01 325 0.03 0.03 Kernel.== > 0.79 1.25 0.01 238 0.04 0.04 File::Stat#size > 0.79 1.26 0.01 240 0.04 0.08 Time#now > 0.79 1.27 0.01 344 0.03 0.03 Fixnum#== > 0.00 1.27 0.00 2 0.00 0.00 IO#sync= > 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: > WavFile#byteRate > 0.00 1.27 0.00 18 0.00 0.00 Class#new > 0.00 1.27 0.00 17 0.00 0.00 Array#to_s > 0.00 1.27 0.00 1 0.00 0.00 FileFormat:: > FileConcat#initialize > 0.00 1.27 0.00 18 0.00 0.00 IO#to_io > 0.00 1.27 0.00 35 0.00 0.00 FileFormat:: > WavFile#audioFormat > 0.00 1.27 0.00 238 0.00 0.08 > > Logger::Formatter#msg2str > > 0.00 1.27 0.00 238 0.00 0.00 String#[] > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#openFile > 0.00 1.27 0.00 28 0.00 0.00 Fixnum#<< > 0.00 1.27 0.00 56 0.00 0.00 Fixnum#>> > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > LogDevice#create_logfile > 0.00 1.27 0.00 298 0.00 0.00 IO#pos= > 0.00 1.27 0.00 17 0.00 0.00 File#exist? > 0.00 1.27 0.00 238 0.00 0.00 Thread#pass > 0.00 1.27 0.00 238 0.00 0.00 NilClass#to_s > 0.00 1.27 0.00 17 0.00 0.00 Array#<< > 0.00 1.27 0.00 51 0.00 0.00 IO#eof? > 0.00 1.27 0.00 9 0.00 2.22 FileFormat:: > FileConcat#writeData > 0.00 1.27 0.00 2 0.00 0.00 Time#to_s > 0.00 1.27 0.00 17 0.00 0.00 > > FileFormat::WavFile#exist? > > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#chunkSize > 0.00 1.27 0.00 238 0.00 0.00 > > Kernel.respond_to? > > 0.00 1.27 0.00 1 0.00 0.00 IO#new > 0.00 1.27 0.00 238 0.00 0.00 Time#strftime > 0.00 1.27 0.00 4 0.00 0.00 Fixnum#| > 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: > WavFile#blockAlign > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#extraParamSize > 0.00 1.27 0.00 6 0.00 0.00 FileTest.exist? > 0.00 1.27 0.00 17 0.00 0.00 IO#open > 0.00 1.27 0.00 355 0.00 0.00 Fixnum#- > 0.00 1.27 0.00 239 0.00 0.00 Array#[] > 0.00 1.27 0.00 18 0.00 1.67 FileFormat:: > WavFile#numChannels > 0.00 1.27 0.00 1 0.00 0.00 Array#size > 0.00 1.27 0.00 20 0.00 0.00 IO#close > 0.00 1.27 0.00 8 0.00 0.00 File#rename > 0.00 1.27 0.00 87 0.00 0.00 String#index > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#initialize > 0.00 1.27 0.00 1 0.00 90.00 FileFormat:: > FileConcat#concatFiles > 0.00 1.27 0.00 2 0.00 0.00 Kernel.open > 0.00 1.27 0.00 2 0.00 0.00 Integer#downto > 0.00 1.27 0.00 4 0.00 0.00 FileFormat:: > FileConcat#writeBytes > 0.00 1.27 0.00 1 0.00 30.00 FileFormat:: > FileConcat#concat_data_block > 0.00 1.27 0.00 476 0.00 0.00 NilClass#nil? > 0.00 1.27 0.00 20 0.00 0.00 File#initialize > 0.00 1.27 0.00 478 0.00 0.00 String#% > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > LogDevice#add_log_header > 0.00 1.27 0.00 18 0.00 2.78 FileFormat:: > WavFile#subChunk1Size > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > LogDevice#shift_log_age > 0.00 1.27 0.00 318 0.00 0.00 IO#write > 0.00 1.27 0.00 238 0.00 0.00 String#<< > 0.00 1.27 0.00 238 0.00 0.00 Kernel.is_a? > 0.00 1.27 0.00 222 0.00 0.00 Fixnum#to_s > 0.00 1.27 0.00 34 0.00 0.00 File#size > 0.00 1.27 0.00 1 0.00 1270.00 #toplevel > > JRuby: > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 10.27 1.25 1.25 203 6.17 7.84 Integer#times > 9.64 2.43 1.17 238 4.94 36.55 Logger#add > 6.57 3.23 0.80 238 3.37 5.86 > > MonitorMixin.mon_exit > > 5.23 3.86 0.64 238 2.68 4.19 Logger:: > Formatter#format_datetime > 4.92 4.46 0.60 238 2.52 19.33 MonitorMixin. > mon_synchronize > 4.37 5.00 0.53 274 1.95 1.95 IO#write > 4.12 5.50 0.50 238 2.11 5.62 Logger:: > LogDevice#check_shift_log > 3.36 5.91 0.41 238 1.72 3.01 > > MonitorMixin.mon_enter > > 3.23 6.30 0.39 497 0.79 1.52 Class#new > 3.08 6.68 0.38 238 1.58 1.65 > > Logger::Formatter#msg2str > > 2.33 6.96 0.28 238 1.19 1.62 > > Logger#format_severity > > 2.33 7.24 0.28 238 1.19 37.75 Logger#info > 2.21 7.51 0.27 238 1.13 7.65 > > Logger::Formatter#call > > 2.18 7.78 0.27 238 1.12 1.12 > > File::Stat#initialize > > 2.08 8.03 0.25 17 14.94 658.12 FileFormat:: > WavFile#getInfo > 1.71 8.24 0.21 238 0.88 1.00 > > MonitorMixin.mon_acquire > > 1.70 8.45 0.21 87 2.38 4.87 FileFormat:: > WavFile#dataPos > 1.62 8.65 0.20 177 1.12 10.50 FileFormat:: > WavFile#readBigNum > 1.51 8.83 0.18 478 0.38 0.55 String#% > 1.44 9.01 0.18 238 0.74 8.39 > > Logger#format_message > > 1.40 9.18 0.17 476 0.36 0.36 NilClass#nil? > 1.37 9.35 0.17 238 0.70 1.08 > > MonitorMixin.mon_release > > 1.32 9.51 0.16 238 0.68 0.68 Time#strftime > 1.31 9.67 0.16 298 0.54 0.54 IO#pos= > 1.23 9.82 0.15 915 0.16 0.16 > > FileFormat::WavFile#file > > 1.19 9.96 0.15 238 0.61 19.94 > > Logger::LogDevice#write > > 1.10 10.10 0.13 952 0.14 0.14 > > ##critical= > > 1.00 10.22 0.12 238 0.51 0.80 MonitorMixin. > mon_check_owner > 0.91 10.33 0.11 530 0.21 0.21 IO#getc > 0.85 10.43 0.10 238 0.43 0.43 Kernel.is_a? > 0.85 10.54 0.10 1060 0.10 0.10 Fixnum#* > 0.83 10.64 0.10 239 0.42 0.42 Array#[] > 0.81 10.74 0.10 476 0.21 0.21 Fixnum#> > 0.75 10.83 0.09 476 0.19 0.19 Array#shift > 0.72 10.91 0.09 965 0.09 0.09 Fixnum#+ > 0.71 11.00 0.09 8 10.75 1494.63 Array#each > 0.71 11.09 0.09 34 2.53 2.53 IO#read > 0.66 11.17 0.08 238 0.34 2.50 File#stat > 0.66 11.25 0.08 238 0.34 0.34 Time#usec > 0.64 11.33 0.08 238 0.33 0.33 NilClass#to_s > 0.62 11.40 0.08 238 0.32 0.32 > > Kernel.respond_to? > > 0.61 11.47 0.07 35 2.11 11.74 FileFormat:: > WavFile#audioFormat > 0.57 11.54 0.07 344 0.20 0.21 Fixnum#== > 0.51 11.61 0.06 476 0.13 0.13 > > ##current > > 0.40 11.65 0.05 238 0.21 0.21 Fixnum#< > 0.33 11.69 0.04 325 0.12 0.12 Kernel.== > 0.32 11.73 0.04 17 2.29 5.71 > > FileFormat::WavFile#exist? > > 0.25 11.76 0.03 1 31.00 31.00 File#initialize > 0.25 11.79 0.03 222 0.14 0.14 Fixnum#to_s > 0.24 11.82 0.03 85 0.34 0.34 FileFormat:: > WavFile#fileDir > 0.21 11.85 0.02 238 0.11 0.11 > > Kernel.block_given? > > 0.20 11.87 0.02 240 0.10 0.10 Time#initialize > 0.19 11.90 0.02 17 1.35 1.71 FileFormat:: > WavFile#readBytes > 0.19 11.92 0.02 238 0.10 0.10 > > ##pass > > 0.17 11.94 0.02 17 1.24 16.71 FileFormat:: > WavFile#extraParamSize > 0.15 11.96 0.02 17 1.06 1.94 FileFormat:: > WavFile#openFile > 0.15 11.98 0.02 238 0.08 0.08 Module#=== > 0.14 11.99 0.02 355 0.05 0.05 Fixnum#- > 0.13 12.01 0.02 34 0.47 23.35 FileFormat:: > WavFile#subChunk2Size > 0.13 12.02 0.02 87 0.18 0.18 IO#readline > 0.10 12.04 0.01 18 0.67 16.67 FileFormat:: > WavFile#bitPerSample > 0.10 12.05 0.01 238 0.05 0.05 File::Stat#size > 0.09 12.06 0.01 238 0.05 0.05 Kernel.nil? > 0.08 12.07 0.01 1 10.00 801.00 FileFormat:: > FileConcat#concatFiles > 0.08 12.08 0.01 17 0.59 0.59 FileFormat:: > WavFile#initialize > 0.07 12.09 0.01 17 0.53 0.53 > > ##open > > 0.07 12.10 0.01 34 0.26 0.38 FileFormat:: > WavFile#fileSize > 0.07 12.11 0.01 18 0.44 5.67 FileFormat:: > WavFile#sampleRate > 0.07 12.11 0.01 87 0.09 0.09 String#index > 0.05 12.12 0.01 9 0.67 4.78 FileFormat:: > FileConcat#writeData > 0.05 12.12 0.01 17 0.35 0.35 FileTest.exist? > 0.04 12.13 0.01 2 2.50 8.00 Integer#downto > 0.04 12.14 0.01 18 0.28 6.17 FileFormat:: > WavFile#subChunk1Size > 0.04 12.14 0.01 18 0.28 4.67 FileFormat:: > WavFile#blockAlign > 0.04 12.15 0.00 17 0.29 0.71 FileFormat:: > WavFile#chunkSize > 0.04 12.15 0.00 18 0.28 12.22 FileFormat:: > WavFile#byteRate > 0.03 12.15 0.00 34 0.12 0.12 FileTest.size > 0.03 12.16 0.00 44 0.09 0.09 IO#putc > 0.03 12.16 0.00 18 0.22 0.22 IO#to_io > 0.02 12.17 0.00 17 0.18 5.82 FileFormat:: > WavFile#extraParams > 0.02 12.17 0.00 2 1.50 3.50 Logger:: > LogDevice#create_logfile > 0.02 12.17 0.00 20 0.15 0.15 IO#close > 0.02 12.17 0.00 17 0.12 0.12 Array#<< > 0.02 12.18 0.00 8 0.25 0.25 > > ##rename > > 0.02 12.18 0.00 28 0.07 0.07 Fixnum#<< > 0.02 12.18 0.00 56 0.04 0.04 Fixnum#>> > 0.02 12.18 0.00 18 0.11 8.94 FileFormat:: > WavFile#numChannels > 0.02 12.18 0.00 51 0.04 0.04 IO#eof > 0.01 12.18 0.00 2 0.50 2.00 Logger:: > LogDevice#add_log_header > 0.01 12.18 0.00 2 0.50 0.50 Time#to_s > 0.00 12.18 0.00 2 0.00 0.00 IO#sync= > 0.00 12.18 0.00 2 0.00 12.50 Logger:: > LogDevice#shift_log_age > 0.00 12.18 0.00 6 0.00 0.00 > > ##exist? > > 0.00 12.18 0.00 1 0.00 0.00 Array#length > 0.00 12.18 0.00 2 0.00 0.00 Kernel.open > 0.00 12.18 0.00 1 0.00 31.00 FileFormat:: > FileConcat#initialize > 0.00 12.18 0.00 17 0.00 0.00 Array#to_s > 0.00 12.18 0.00 1 0.00 209.00 FileFormat:: > FileConcat#concat_data_block > 0.00 12.18 0.00 4 0.00 0.00 Fixnum#| > 0.00 12.18 0.00 4 0.00 1.00 FileFormat:: > FileConcat#writeBytes > 0.00 12.19 0.00 1 0.00 12187.00 #toplevel > > This performance of JRuby is rather bad. Reasons may come from: > 1. JRuby is in nature very slow. We can not do anything to this > 2. JRuby's startup time is longer than that of Ruby. I wonder this > situation would be improved if we have had on in-memory JVM > > > Peter K Chan wrote: > Not anymore, Nate. :) > > JRuby WAS slow six months ago, but it has come a long way. Check this > > out: > > > > http://headius.blogspot.com/2007/04/paving-road-to-jruby-10-performance. > html > > Summary: In interpretive mode, JRuby is no more than 2x slower, and > that's including JVM startup and lack of hotspot warm up. In > unoptimized compiled mode, JRuby often beats C Ruby. I have been using > JRuby in my project, and I haven't had any performance complaints > since 2 months ago. > > Peter > ________________________________________ > From: chicagogroup-members-list-bounces at rubyforge.org [mailto: > chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate > > Kirby > > Sent: Tuesday, May 29, 2007 2:23 AM > To: Chirb discussion list > Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t > > Peter, > > JRuby is slow. Try RJB (http://rjb.rubyforge.org/) > > Nate > > Peter K Chan wrote: > Sure! I will be up for some Uger-hacking/feedback-taking (I also need > > to > > apply Colin's patch from a while ago and push it out). > > Hmm...maybe I should think of a lightning talk on JRuby or something. > > Peter > > -----Original Message----- > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Evan Farrar > Sent: Monday, May 28, 2007 5:51 PM > To: Chirb discussion list > Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t > > Woohoo Lightning talks! I will definitely come with something. I also > would like to call together a uger hacksession if Peter Chang is > around for the meeting. > > On 5/28/07, Josh Cronemeyer wrote: > > Ok, nobody signed up for the talk and we are a week away from the next > CHIRB. Soooo, unless anyone objects I think we should have another > "lightning talk / code pit" session like the one last december. If > > you can > > prepare something that you can get through in 10 minutes or so, please > > do. > > Alternatively you can put out a request for a talk on a certain topic > > and > > perhaps that will inspire somebody. I'm mulling over a topic just to > > force > > myself to learn something new (Why's camping framework). But I make > > no > > promises :) Let's have fun with this and take advantage of the chance > > for > > all of us to talk. No pressure!!!! > > http://chirb.org/event/show/18 > > Josh Cronemeyer > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: rjb_test.zip Type: application/x-zip-compressed Size: 1262136 bytes Desc: not available Url : http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/052dce0a/attachment-0002.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: hanoi.zip Type: application/x-zip-compressed Size: 1299 bytes Desc: not available Url : http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/052dce0a/attachment-0003.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hanoi_jruby.rb Url: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/052dce0a/attachment-0002.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jruby.sh Url: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/052dce0a/attachment-0003.pl From jason at hostedlabs.com Mon Jun 18 11:38:19 2007 From: jason at hostedlabs.com (Jason Rexilius) Date: Mon, 18 Jun 2007 10:38:19 -0500 Subject: [Chirb] BARcamp Chicago is this weekend! In-Reply-To: <51933.68.72.119.127.1182134921.squirrel@acm.cs.uic.edu> References: <51933.68.72.119.127.1182134921.squirrel@acm.cs.uic.edu> Message-ID: <4676A6EB.2060301@hostedlabs.com> Hi Everyone! BARcamp is this weekend (Sat-Sun, 23-24 June) and I am super excited! Everyone has really come together for this. We have a lot of great talks and ideas floating around and everyone seems to be pitching in something to help. The last organizer meet-up is tonight at Goose Island(clyborn) @ 7:00. There are also a couple other events this week worth checking out that I want to mention. Beer and ideas to get primed for BARcamp ;-) - Kristen Nicole's Web Ascent is happening Wed the 20th. http://www.webascentevents.com/ - MIT-EF has this cool Whiteboard competition happening Tue the 19th. http://www.mitefchicago.org/dojo/18/v.jsp?p=/BelowtheRadar Uuhh.. thats all I can remember. Its going to be a fun week in the Chicago tech world.. So back to BARcamp. Some of the stuff that is going to be happening this weekend is: - Dave Williams talk on building cross platform widgets with wxWidgets - FRDCSA A.I. talk on learning coding libraries through operator learning and representation - Linux install fest and lightening talks on a few special purpose distros - Tristan Sloughter teaches us how to Brew Beer at Home! - Kirix talks about their Human UI for browsing web data - MobileWeb 2.0 hackathon, building apps for mobile devices. - Perry spins the trax, live webcast for the kids at home - Humanized talks about Enso - ChicagoBeta-BARcamp Job Board - exploration, the joy of learning things and lots of liquor Some last shout-outs for help: - video peoples, help capture talks and goings on. - please bring power strips, Cat5 cables, extension cords, pillows to sit on - bring an idea for a code sprint Thats it. Looking forward to seeing you all there! -jason jason at hostedlabs.com 847.208.1000 event details: http://barcampchicago.com/ From sean.seanlynch at gmail.com Mon Jun 18 13:03:28 2007 From: sean.seanlynch at gmail.com (Sean Lynch) Date: Mon, 18 Jun 2007 12:03:28 -0500 Subject: [Chirb] [JOB] Agile Ruby Developer in Western Suburbs In-Reply-To: <744d5a650706120642t470d9130j9d75865053c899af@mail.gmail.com> References: <744d5a650706120642t470d9130j9d75865053c899af@mail.gmail.com> Message-ID: <40651cc90706181003q619fb7acm63d3748dc2caf711@mail.gmail.com> Kevin, Sorry for the late reply to your e-mail, but I have been out of town on vacation. While I can answer 'yes' to all of those questions (with the qualification that I have more than a decade's experience with coding in general for #2), I also have to tell you that I have just started on a 6 month contract at The Northern Trust. So I'm afraid I am currently off the market. I'll keep you contact information and forward it to anyone I know is looking. I was at the 2007 Rails Conf in Portland a few weeks ago, and there are a lot of coders looking for work. Unfortunately(for recruiters not coders) it seems that there were about twice as many companies looking to hire. Good luck in your search, and I'll pass your contact info on at the User Group meetings. Thanks, Sean lynch On 6/12/07, Kevin Taylor wrote: > We are looking for 1 full-time Ruby developer to work in our studio in > Wheaton, IL. > > Do you: > - thrive in an open, honest, and collaborative environment? > > Do you: > - have at least 6 months of Ruby and 2 years of general coding experience? > > Do you: > - want to work on multiple Ruby on Rails projects in a team environment? > > Do you: > - gain satisfaction from teaching and mentoring others while growing your > own skills? > > If you can answer yes to all of the above questions and you want to be part > of a fast growing agile consulting team, send a resume and a short letter > describing why you want to be considered. > > Obtiva is a rapidly growing agile consulting team where team members spend > their time doing in-the-trenches software development leveraging our agile > practices, training other developers in technology and methodology topics, > and engaging in short-term, intensive technology/agile coaching. We are > actively involved in the developer community and frequently sponsor our team > members to present what we have learned at local and national conferences. > > Our client list is diverse and includes entertainment companies, retailers, > hedge funds, and Web 2.0 startups. > > You will be working in our Wheaton office. We are located near I-88 and > within walking distance of the train station. > > Please send to jobs at obtiva.com. > > www.obtiva.com > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > From peter at oaktop.com Mon Jun 18 14:02:36 2007 From: peter at oaktop.com (Peter K Chan) Date: Mon, 18 Jun 2007 14:02:36 -0400 Subject: [Chirb] JRuby performance In-Reply-To: <46759AD3.2060209@yahoo.com> References: <465BF078.8050808@yahoo.com> <465CC5FD.7030505@yahoo.com> <465D85AD.3010700@yahoo.com> <4673D78A.50001@yahoo.com> <46759AD3.2060209@yahoo.com> Message-ID: Nate, "Slow" is a relative term. JNI is fast enough for most perception, but it is still marshalling calls across the JVM boundary. In general, if you do intensive benchmarking, then pure Java method call inside the JVM is going to be faster than JNI call across JVM/JNI boundary. I took a look at the code that you posted, and I have two observations: test_controller_test.rb (rjb) - I am not sure what is being benchmark in this file. Correct me if I am wrong, but it looks like the code is only calling the Java method *once* using RJB (presumably with JNI), but then the bulk of the execution is done inside the JVM with Java code. In other words, it looks like a benchmark of the Java code performance, rather than a benchmark of RJB->Java invocation performance. The same seems to be true with the hanoi_jruby.rb, which also seems to make just one call into the Java method from JRuby. Hanoi.java - The move method has an empty body, which would have been optimized away by the Hotspot JIT as dead code. So, the result may have been skewed toward Java's favor, since the JVM is smart enough to skip the move(char, char) completely, whereas C Ruby would still make that method dispatch. By my own quick test, the empty body ran in 1.8s, where as adding a Class.staticField++ statement increases the execution time to 2.3s (careful, you can't just increment the local variable, hotspot will still spot the lack of effect and optimize that away). This optimization only shows up in the server VM though. I am sure that Java is faster anyway, but in this case, it is also smarter and cheated. :) The problem with benchmarking with Hotspot is that it is so smart, you have to work hard to make sure that your code is actually still executed. Peter -----Original Message----- From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate Kirby Sent: Sunday, June 17, 2007 3:34 PM To: Chirb discussion list Subject: Re: [Chirb] JRuby performance Peter, Peter K Chan wrote: > Nate, > Thanks for reporting back with your findings. For the past few months I have heard reports about how Java is approaching or even exceeding C speed on certain algorithmic implementation. This could explain why writing the Tower of Hanoi is so much faster in Java then Ruby - the algorithm is probably well-optimized by the JVM just-in-time compiler, and you are essentially comparing purely-interpreted Ruby speed with native C speed. > This could be. > Also, since JRuby runs inside the JVM, that would explain why it is faster than RJB. I imagine that RJB is using Java Native Interface to call Java code, which can be slow. > RHB does use JNI - but I have not experienced JNI as "slow" before. > Can you post (or send me privately) the code that you used to > benchmark? Reading from your email, it sounds like you did a bunch of > test, but it wasn't very clear exactly what you tested for. (Hanoi in > Java vs. Hanoi in C Ruby? Hanoi in C Ruby vs. Hanoi in JRuby? RJB vs. > JRuby in invoking Java code?) > Attached to this email please find code samples. > I don't think I have any more comments to add to this, but I wouldn't mind taking a look at the code. > Blessings, Nate > Thanks, > > Peter > > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > Sent: Saturday, June 16, 2007 7:29 AM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > I don't like eating crow, but it is better than starving. The current > results are (the I in this is not form me but a colleague) > [Summation: Performance for CPU indicates JRuby is the way to go] > > ############################################### > Here are the results: > > 1. Java is much faster than Ruby. Implementing the Hanoi algorithm in > Java, either calling from JRuby or through RJB gains the hundreds of > times of performance boost. At first I let the number of disks be 28, > the same as last time I sent you, but this time only takes a few > seconds. > ---------------------------------------------------------------------- > -------------- clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh > Loaded suite test/functional/test_controller_test > Started > Number of disks: 28 > Start Time: 1181985788.69547 > Finish Time: 1181985796.42535 > Time used: 7.72987794876099 seconds > . > Finished in 7.808512 seconds. > > 1 tests, 0 assertions, 0 failures, 0 errors > ---------------------------------------------------------------------- > ------ clive at epiphany:~/Desktop/performance$ ./jruby.sh Number of > disks: 28 Start Time: 1181984655.81 Finish Time: 1181984659.713 Time > used: 3.9030001163482666 seconds > ---------------------------------------------------------------------- > ----------- > > 2. Since both only took a few seconds, I increased the number of disks > to gain more accurate results, and found that calling Java code from > JRuby is faster than calling through RJB: > ---------------------------------------------------------------------- > --------- clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh > Loaded suite test/functional/test_controller_test > Started > Number of disks: 35 > Start Time: 1181985899.15607 > Finish Time: 1181986895.74254 > Time used: 996.586473941803 seconds > . > Finished in 996.662218 seconds. > ---------------------------------------------------------------------- > --------- clive at epiphany:~/Desktop/performance$ ./jruby.sh Number of > disks: 35 Start Time: 1181988594.084 Finish Time: 1181989376.494 Time > used: 782.4099998474121 seconds > ---------------------------------------------------------------------- > -------------- > A few notes: > 1. I don't know how to use RJB in ruby without rails, so I created a > rails project and wrote a functional test to host those code. The > rjb.sh in the zip file is what I used to run the test. I used Java > server VM to run the Java code. I wonder if there are more things to > do to tune the performance of RJB. > 2. For JRuby, I used all performance tuning methods I used last time, > plus this time I used Java server VM. This can be seen in jruby.sh 3. > hanoi.zip is the Java code I used. I have trouble in passing arguments > of primitive types to Java, both in rjb and jruby, so I overloaded the > method with arguments of classes. But in terms of performance > comparison, I don't think that matters. > ############################################## > > Needless to say we are investigation JRuby seriously now. If you want the source for these tests I can provide it. > > Blessing, > Nate > > > > > Peter K Chan wrote: > Nate, > Thanks for getting back to me. I haven't seen the source for your > benchmark, but I imagine that it may be doing some specific processing > that JRuby is slow at (i.e. looking at the method names, it seems to > be doing quite a bit of byte shuffling?). > > Also, just a guess, but the 8x difference worsening to 14x times may > be due to JVM startup cost (a real possibility; once you step into > single digit second run time). > > In any case, here is a link which explains how to tune JRuby for > performance, including how to disable Object Space and turn on compiler: > > http://www.headius.com/jrubywiki/index.php/Performance_Tuning > > Just to put things in context: JRuby shines when you are doing > integration with Java and long running server processes. One time > scripts may still be a sore point for the foreseeable future, simply > because of the JVM start-up and warm-up cost. > > Peter > > -----Original Message----- > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > Sent: Wednesday, May 30, 2007 9:10 AM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > This is the reponse I got: > > ************* > The JVM on my Ubuntu machine is Sun's: > > clive at epiphany:~$ java -version > java version "1.6.0" > Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) > Client VM (build 1.6.0-b105, mixed mode, sharing) > > And I use the latest version of JRuby. I ran that piece of code with > profiling again on my machine, which is very old one, C Ruby took 2.72 > sec, JRuby took 22.78 sec. 8.375 times difference. > Then I changed the code, took out profiler, and printed out the start > time and finish time only, C Ruby took 0.27586 sec, JRuby took 4.074 > sec: 14.768360763 times difference. > > The attachment is the raw data. I did not: > -disable object space (I did some research, but have no idea of how to > do that. The hotspot server seemed to have some option about size of > object space, but I don't think it allows us to set the size to 0) > > -turn on the JRuby AOT or JIT compiler ( I have no idea of what that > is) > > It seems that the performance under default setting is still bad. > > ************** > Blessings, > Nate > > Peter K Chan wrote: > > Sure, Nate. > > I do concede that JRuby is not yet a Ruby drop in replacement, at > > least not for running small scripts. It takes only 5 minutes to tweak > the performance, but it is still 5 minutes more than C Ruby. Where > JRuby really shines is in Java integration and scalability (e.g. > running multiple rails instances within a single JVM, connecting to a > JDBC database). > > I would be very interested in seeing what kind of performance you get > > for your evaluation. > > Peter > ________________________________________ > From: chicagogroup-members-list-bounces at rubyforge.org > > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > > Sent: Tuesday, May 29, 2007 7:32 PM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > I actually had someone else do it. I will forward your suggestions > > along to them. I have had the impression in the past that individual > vendors VMs were often faster than Suns for their platform. That is > possibly in error, but in the late 90's it was not. > > Thanks, > Nate > > Peter K Chan wrote: > Nate, > Josh has already brought up most of what I was going to reply to > > you, but let me just highlight these factors, which may explain your > performance result: > > - Are you using a modern JVM, such as Sun 1.6.0, with hotspot/JIT > > compilation? > > - Did you disable object space? (Makes a huge 20% - 40% difference, I > > disable it in all my apps) > > - Did you pull the latest trunk or at least RC version of JRuby? > - Did you turn on the JRuby AOT or JIT compiler? > - I think that JRuby's set_trace_func is slow; therefore, if you use > > profile.rb, you may be incurring large profiling cost (actually, > set_trace_func isn't working in current JRuby compiler, so you must > have been running JRuby in pure interpretive mode). > > > Also, keep in mind that the benchmark result I linked to > > include JVM startup time. If you consider that the JVM takes a few > seconds to fully warm up, and most benchmark finishes in a few > seconds, JRuby's result is even more impressive. > > Don't take my word for it. Run your benchmark with the right > > settings, and you can see for yourself. :) > > Peter > ________________________________________ > From: chicagogroup-members-list-bounces at rubyforge.org > > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Josh Cronemeyer > > Sent: Tuesday, May 29, 2007 11:11 AM > To: Chirb discussion list > Subject: [Chirb] JRuby performance > > > discussion moved from this thread: Re: [Chirb] time to rsvp for the > > mystery meeting! W00t > > Nate, > > I've heard alot of good stuff about jruby performance, not from just > > peter. > > > [programmer at Mark ~]$ java --version > java version "1.4.2" > gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) > > I think you should run your tests with a real JVM (like sun's > > implementation). You are using gij which is a java interpretor. GIJ > is a part of the GCJ project. GCJ is a very different beast than > sun's implementation. The idea behind GCJ is that java is compiled > down to your specific platform's machine code. So they bypass the jvm > all together. This sounds like it would be faster, but it really > isn't for many things because sun's just in time compilation can > actually compile the same code in different ways depending on context > in order to optimize execution. I'm not sure if Jruby uses runtime > code loading or generation (i wouldn't be surprised though). If that > is the case GCJ is SUPER slow for those types of operations because > that is when the gij interpreter kicks in. The interpreter is realizing no benefits from > optimization or compilation. > > The short of it: I wouldn't call my tests definitive until I was using > > sun's jvm. > > Josh Cronemeyer > > chicagogroup-members-list-bounces at rubyforge.org wrote on 05/29/2007 > > 04:20:56 AM: > > > Peter, > > I can take your word for it....or I can check the performance stats we > just did a few weeks ago JRuby was 10x slower than ruby at the command > line on a Fedora box. > > Nate > > STATS > > [programmer at Mark ~]$ java --version > java version "1.4.2" > gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) > > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > > is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > PURPOSE. > > I did not change the default JVM. I used the Ruby project > concatenating wav files and profiler to see the performance data. This > is the result: > Ruby: > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 10.24 0.13 0.13 238 0.55 1.13 > > MonitorMixin.mon_exit > > 7.09 0.22 0.09 238 0.38 2.27 > > MonitorMixin.synchronize > > 6.30 0.30 0.08 238 0.34 3.57 Logger#add > 5.51 0.37 0.07 238 0.29 0.34 Logger:: > Formatter#format_datetime > 4.72 0.43 0.06 17 3.53 68.82 FileFormat:: > WavFile#getInfo > 4.72 0.49 0.06 203 0.30 0.69 Integer#times > 3.94 0.54 0.05 238 0.21 0.42 Logger:: > LogDevice#check_shift_log > 3.15 0.58 0.04 238 0.17 0.25 > > MonitorMixin.mon_release > > 3.15 0.62 0.04 238 0.17 0.34 > > MonitorMixin.mon_enter > > 2.36 0.65 0.03 256 0.12 0.12 String#+ > 2.36 0.68 0.03 87 0.34 0.57 FileFormat:: > WavFile#dataPos > 2.36 0.71 0.03 177 0.17 0.85 FileFormat:: > WavFile#readBigNum > 2.36 0.74 0.03 530 0.06 0.06 IO#getc > 2.36 0.77 0.03 8 3.75 155.00 Array#each > 2.36 0.80 0.03 476 0.06 0.06 Thread#current > 2.36 0.83 0.03 238 0.13 0.13 > > Logger#format_severity > > 2.36 0.86 0.03 238 0.13 0.21 MonitorMixin. > mon_check_owner > 2.36 0.89 0.03 952 0.03 0.03 Thread#critical= > 2.36 0.92 0.03 238 0.13 0.55 > > Logger::Formatter#call > > 1.57 0.94 0.02 476 0.04 0.04 Array#shift > 1.57 0.96 0.02 1060 0.02 0.02 Fixnum#* > 1.57 0.98 0.02 238 0.08 0.08 Module#=== > 1.57 1.00 0.02 238 0.08 0.08 IO#stat > 1.57 1.02 0.02 87 0.23 0.23 IO#readline > 1.57 1.04 0.02 476 0.04 0.04 Fixnum#> > 1.57 1.06 0.02 965 0.02 0.02 Fixnum#+ > 0.79 1.07 0.01 17 0.59 2.94 FileFormat:: > WavFile#extraParams > 0.79 1.08 0.01 238 0.04 0.04 Kernel.nil? > 0.79 1.09 0.01 240 0.04 0.04 Time#initialize > 0.79 1.10 0.01 44 0.23 0.23 IO#putc > 0.79 1.11 0.01 34 0.29 0.29 FileFormat:: > WavFile#fileSize > 0.79 1.12 0.01 238 0.04 0.59 > > Logger#format_message > > 0.79 1.13 0.01 34 0.29 0.29 IO#read > 0.79 1.14 0.01 17 0.59 0.59 FileFormat:: > WavFile#readBytes > 0.79 1.15 0.01 238 0.04 0.04 Time#usec > 0.79 1.16 0.01 238 0.04 0.04 > > Kernel.block_given? > > 0.79 1.17 0.01 238 0.04 2.31 > > Logger::LogDevice#write > > 0.79 1.18 0.01 18 0.56 0.56 FileFormat:: > WavFile#bitPerSample > 0.79 1.19 0.01 34 0.29 1.47 FileFormat:: > WavFile#subChunk2Size > 0.79 1.20 0.01 238 0.04 0.13 > > MonitorMixin.mon_acquire > > 0.79 1.21 0.01 238 0.04 0.04 Fixnum#< > 0.79 1.22 0.01 238 0.04 3.61 Logger#info > 0.79 1.23 0.01 18 0.56 1.67 FileFormat:: > WavFile#sampleRate > 0.79 1.24 0.01 325 0.03 0.03 Kernel.== > 0.79 1.25 0.01 238 0.04 0.04 File::Stat#size > 0.79 1.26 0.01 240 0.04 0.08 Time#now > 0.79 1.27 0.01 344 0.03 0.03 Fixnum#== > 0.00 1.27 0.00 2 0.00 0.00 IO#sync= > 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: > WavFile#byteRate > 0.00 1.27 0.00 18 0.00 0.00 Class#new > 0.00 1.27 0.00 17 0.00 0.00 Array#to_s > 0.00 1.27 0.00 1 0.00 0.00 FileFormat:: > FileConcat#initialize > 0.00 1.27 0.00 18 0.00 0.00 IO#to_io > 0.00 1.27 0.00 35 0.00 0.00 FileFormat:: > WavFile#audioFormat > 0.00 1.27 0.00 238 0.00 0.08 > > Logger::Formatter#msg2str > > 0.00 1.27 0.00 238 0.00 0.00 String#[] > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#openFile > 0.00 1.27 0.00 28 0.00 0.00 Fixnum#<< > 0.00 1.27 0.00 56 0.00 0.00 Fixnum#>> > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > LogDevice#create_logfile > 0.00 1.27 0.00 298 0.00 0.00 IO#pos= > 0.00 1.27 0.00 17 0.00 0.00 File#exist? > 0.00 1.27 0.00 238 0.00 0.00 Thread#pass > 0.00 1.27 0.00 238 0.00 0.00 NilClass#to_s > 0.00 1.27 0.00 17 0.00 0.00 Array#<< > 0.00 1.27 0.00 51 0.00 0.00 IO#eof? > 0.00 1.27 0.00 9 0.00 2.22 FileFormat:: > FileConcat#writeData > 0.00 1.27 0.00 2 0.00 0.00 Time#to_s > 0.00 1.27 0.00 17 0.00 0.00 > > FileFormat::WavFile#exist? > > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#chunkSize > 0.00 1.27 0.00 238 0.00 0.00 > > Kernel.respond_to? > > 0.00 1.27 0.00 1 0.00 0.00 IO#new > 0.00 1.27 0.00 238 0.00 0.00 Time#strftime > 0.00 1.27 0.00 4 0.00 0.00 Fixnum#| > 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: > WavFile#blockAlign > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#extraParamSize > 0.00 1.27 0.00 6 0.00 0.00 FileTest.exist? > 0.00 1.27 0.00 17 0.00 0.00 IO#open > 0.00 1.27 0.00 355 0.00 0.00 Fixnum#- > 0.00 1.27 0.00 239 0.00 0.00 Array#[] > 0.00 1.27 0.00 18 0.00 1.67 FileFormat:: > WavFile#numChannels > 0.00 1.27 0.00 1 0.00 0.00 Array#size > 0.00 1.27 0.00 20 0.00 0.00 IO#close > 0.00 1.27 0.00 8 0.00 0.00 File#rename > 0.00 1.27 0.00 87 0.00 0.00 String#index > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#initialize > 0.00 1.27 0.00 1 0.00 90.00 FileFormat:: > FileConcat#concatFiles > 0.00 1.27 0.00 2 0.00 0.00 Kernel.open > 0.00 1.27 0.00 2 0.00 0.00 Integer#downto > 0.00 1.27 0.00 4 0.00 0.00 FileFormat:: > FileConcat#writeBytes > 0.00 1.27 0.00 1 0.00 30.00 FileFormat:: > FileConcat#concat_data_block > 0.00 1.27 0.00 476 0.00 0.00 NilClass#nil? > 0.00 1.27 0.00 20 0.00 0.00 File#initialize > 0.00 1.27 0.00 478 0.00 0.00 String#% > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > LogDevice#add_log_header > 0.00 1.27 0.00 18 0.00 2.78 FileFormat:: > WavFile#subChunk1Size > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > LogDevice#shift_log_age > 0.00 1.27 0.00 318 0.00 0.00 IO#write > 0.00 1.27 0.00 238 0.00 0.00 String#<< > 0.00 1.27 0.00 238 0.00 0.00 Kernel.is_a? > 0.00 1.27 0.00 222 0.00 0.00 Fixnum#to_s > 0.00 1.27 0.00 34 0.00 0.00 File#size > 0.00 1.27 0.00 1 0.00 1270.00 #toplevel > > JRuby: > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 10.27 1.25 1.25 203 6.17 7.84 Integer#times > 9.64 2.43 1.17 238 4.94 36.55 Logger#add > 6.57 3.23 0.80 238 3.37 5.86 > > MonitorMixin.mon_exit > > 5.23 3.86 0.64 238 2.68 4.19 Logger:: > Formatter#format_datetime > 4.92 4.46 0.60 238 2.52 19.33 MonitorMixin. > mon_synchronize > 4.37 5.00 0.53 274 1.95 1.95 IO#write > 4.12 5.50 0.50 238 2.11 5.62 Logger:: > LogDevice#check_shift_log > 3.36 5.91 0.41 238 1.72 3.01 > > MonitorMixin.mon_enter > > 3.23 6.30 0.39 497 0.79 1.52 Class#new > 3.08 6.68 0.38 238 1.58 1.65 > > Logger::Formatter#msg2str > > 2.33 6.96 0.28 238 1.19 1.62 > > Logger#format_severity > > 2.33 7.24 0.28 238 1.19 37.75 Logger#info > 2.21 7.51 0.27 238 1.13 7.65 > > Logger::Formatter#call > > 2.18 7.78 0.27 238 1.12 1.12 > > File::Stat#initialize > > 2.08 8.03 0.25 17 14.94 658.12 FileFormat:: > WavFile#getInfo > 1.71 8.24 0.21 238 0.88 1.00 > > MonitorMixin.mon_acquire > > 1.70 8.45 0.21 87 2.38 4.87 FileFormat:: > WavFile#dataPos > 1.62 8.65 0.20 177 1.12 10.50 FileFormat:: > WavFile#readBigNum > 1.51 8.83 0.18 478 0.38 0.55 String#% > 1.44 9.01 0.18 238 0.74 8.39 > > Logger#format_message > > 1.40 9.18 0.17 476 0.36 0.36 NilClass#nil? > 1.37 9.35 0.17 238 0.70 1.08 > > MonitorMixin.mon_release > > 1.32 9.51 0.16 238 0.68 0.68 Time#strftime > 1.31 9.67 0.16 298 0.54 0.54 IO#pos= > 1.23 9.82 0.15 915 0.16 0.16 > > FileFormat::WavFile#file > > 1.19 9.96 0.15 238 0.61 19.94 > > Logger::LogDevice#write > > 1.10 10.10 0.13 952 0.14 0.14 > > ##critical= > > 1.00 10.22 0.12 238 0.51 0.80 MonitorMixin. > mon_check_owner > 0.91 10.33 0.11 530 0.21 0.21 IO#getc > 0.85 10.43 0.10 238 0.43 0.43 Kernel.is_a? > 0.85 10.54 0.10 1060 0.10 0.10 Fixnum#* > 0.83 10.64 0.10 239 0.42 0.42 Array#[] > 0.81 10.74 0.10 476 0.21 0.21 Fixnum#> > 0.75 10.83 0.09 476 0.19 0.19 Array#shift > 0.72 10.91 0.09 965 0.09 0.09 Fixnum#+ > 0.71 11.00 0.09 8 10.75 1494.63 Array#each > 0.71 11.09 0.09 34 2.53 2.53 IO#read > 0.66 11.17 0.08 238 0.34 2.50 File#stat > 0.66 11.25 0.08 238 0.34 0.34 Time#usec > 0.64 11.33 0.08 238 0.33 0.33 NilClass#to_s > 0.62 11.40 0.08 238 0.32 0.32 > > Kernel.respond_to? > > 0.61 11.47 0.07 35 2.11 11.74 FileFormat:: > WavFile#audioFormat > 0.57 11.54 0.07 344 0.20 0.21 Fixnum#== > 0.51 11.61 0.06 476 0.13 0.13 > > ##current > > 0.40 11.65 0.05 238 0.21 0.21 Fixnum#< > 0.33 11.69 0.04 325 0.12 0.12 Kernel.== > 0.32 11.73 0.04 17 2.29 5.71 > > FileFormat::WavFile#exist? > > 0.25 11.76 0.03 1 31.00 31.00 File#initialize > 0.25 11.79 0.03 222 0.14 0.14 Fixnum#to_s > 0.24 11.82 0.03 85 0.34 0.34 FileFormat:: > WavFile#fileDir > 0.21 11.85 0.02 238 0.11 0.11 > > Kernel.block_given? > > 0.20 11.87 0.02 240 0.10 0.10 Time#initialize > 0.19 11.90 0.02 17 1.35 1.71 FileFormat:: > WavFile#readBytes > 0.19 11.92 0.02 238 0.10 0.10 > > ##pass > > 0.17 11.94 0.02 17 1.24 16.71 FileFormat:: > WavFile#extraParamSize > 0.15 11.96 0.02 17 1.06 1.94 FileFormat:: > WavFile#openFile > 0.15 11.98 0.02 238 0.08 0.08 Module#=== > 0.14 11.99 0.02 355 0.05 0.05 Fixnum#- > 0.13 12.01 0.02 34 0.47 23.35 FileFormat:: > WavFile#subChunk2Size > 0.13 12.02 0.02 87 0.18 0.18 IO#readline > 0.10 12.04 0.01 18 0.67 16.67 FileFormat:: > WavFile#bitPerSample > 0.10 12.05 0.01 238 0.05 0.05 File::Stat#size > 0.09 12.06 0.01 238 0.05 0.05 Kernel.nil? > 0.08 12.07 0.01 1 10.00 801.00 FileFormat:: > FileConcat#concatFiles > 0.08 12.08 0.01 17 0.59 0.59 FileFormat:: > WavFile#initialize > 0.07 12.09 0.01 17 0.53 0.53 > > ##open > > 0.07 12.10 0.01 34 0.26 0.38 FileFormat:: > WavFile#fileSize > 0.07 12.11 0.01 18 0.44 5.67 FileFormat:: > WavFile#sampleRate > 0.07 12.11 0.01 87 0.09 0.09 String#index > 0.05 12.12 0.01 9 0.67 4.78 FileFormat:: > FileConcat#writeData > 0.05 12.12 0.01 17 0.35 0.35 FileTest.exist? > 0.04 12.13 0.01 2 2.50 8.00 Integer#downto > 0.04 12.14 0.01 18 0.28 6.17 FileFormat:: > WavFile#subChunk1Size > 0.04 12.14 0.01 18 0.28 4.67 FileFormat:: > WavFile#blockAlign > 0.04 12.15 0.00 17 0.29 0.71 FileFormat:: > WavFile#chunkSize > 0.04 12.15 0.00 18 0.28 12.22 FileFormat:: > WavFile#byteRate > 0.03 12.15 0.00 34 0.12 0.12 FileTest.size > 0.03 12.16 0.00 44 0.09 0.09 IO#putc > 0.03 12.16 0.00 18 0.22 0.22 IO#to_io > 0.02 12.17 0.00 17 0.18 5.82 FileFormat:: > WavFile#extraParams > 0.02 12.17 0.00 2 1.50 3.50 Logger:: > LogDevice#create_logfile > 0.02 12.17 0.00 20 0.15 0.15 IO#close > 0.02 12.17 0.00 17 0.12 0.12 Array#<< > 0.02 12.18 0.00 8 0.25 0.25 > > ##rename > > 0.02 12.18 0.00 28 0.07 0.07 Fixnum#<< > 0.02 12.18 0.00 56 0.04 0.04 Fixnum#>> > 0.02 12.18 0.00 18 0.11 8.94 FileFormat:: > WavFile#numChannels > 0.02 12.18 0.00 51 0.04 0.04 IO#eof > 0.01 12.18 0.00 2 0.50 2.00 Logger:: > LogDevice#add_log_header > 0.01 12.18 0.00 2 0.50 0.50 Time#to_s > 0.00 12.18 0.00 2 0.00 0.00 IO#sync= > 0.00 12.18 0.00 2 0.00 12.50 Logger:: > LogDevice#shift_log_age > 0.00 12.18 0.00 6 0.00 0.00 > > ##exist? > > 0.00 12.18 0.00 1 0.00 0.00 Array#length > 0.00 12.18 0.00 2 0.00 0.00 Kernel.open > 0.00 12.18 0.00 1 0.00 31.00 FileFormat:: > FileConcat#initialize > 0.00 12.18 0.00 17 0.00 0.00 Array#to_s > 0.00 12.18 0.00 1 0.00 209.00 FileFormat:: > FileConcat#concat_data_block > 0.00 12.18 0.00 4 0.00 0.00 Fixnum#| > 0.00 12.18 0.00 4 0.00 1.00 FileFormat:: > FileConcat#writeBytes > 0.00 12.19 0.00 1 0.00 12187.00 #toplevel > > This performance of JRuby is rather bad. Reasons may come from: > 1. JRuby is in nature very slow. We can not do anything to this 2. > JRuby's startup time is longer than that of Ruby. I wonder this > situation would be improved if we have had on in-memory JVM > > > Peter K Chan wrote: > Not anymore, Nate. :) > > JRuby WAS slow six months ago, but it has come a long way. Check this > > out: > > > > http://headius.blogspot.com/2007/04/paving-road-to-jruby-10-performance. > html > > Summary: In interpretive mode, JRuby is no more than 2x slower, and > that's including JVM startup and lack of hotspot warm up. In > unoptimized compiled mode, JRuby often beats C Ruby. I have been using > JRuby in my project, and I haven't had any performance complaints > since 2 months ago. > > Peter > ________________________________________ > From: chicagogroup-members-list-bounces at rubyforge.org [mailto: > chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate > > Kirby > > Sent: Tuesday, May 29, 2007 2:23 AM > To: Chirb discussion list > Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t > > Peter, > > JRuby is slow. Try RJB (http://rjb.rubyforge.org/) > > Nate > > Peter K Chan wrote: > Sure! I will be up for some Uger-hacking/feedback-taking (I also need > > to > > apply Colin's patch from a while ago and push it out). > > Hmm...maybe I should think of a lightning talk on JRuby or something. > > Peter > > -----Original Message----- > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Evan Farrar > Sent: Monday, May 28, 2007 5:51 PM > To: Chirb discussion list > Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t > > Woohoo Lightning talks! I will definitely come with something. I also > would like to call together a uger hacksession if Peter Chang is > around for the meeting. > > On 5/28/07, Josh Cronemeyer wrote: > > Ok, nobody signed up for the talk and we are a week away from the next > CHIRB. Soooo, unless anyone objects I think we should have another > "lightning talk / code pit" session like the one last december. If > > you can > > prepare something that you can get through in 10 minutes or so, please > > do. > > Alternatively you can put out a request for a talk on a certain topic > > and > > perhaps that will inspire somebody. I'm mulling over a topic just to > > force > > myself to learn something new (Why's camping framework). But I make > > no > > promises :) Let's have fun with this and take advantage of the chance > > for > > all of us to talk. No pressure!!!! > > http://chirb.org/event/show/18 > > Josh Cronemeyer > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > From hubrix at gmail.com Mon Jun 18 14:13:30 2007 From: hubrix at gmail.com (Mark Alexander Friedgan) Date: Mon, 18 Jun 2007 13:13:30 -0500 Subject: [Chirb] JRuby performance In-Reply-To: References: <465BF078.8050808@yahoo.com> <465CC5FD.7030505@yahoo.com> <465D85AD.3010700@yahoo.com> <4673D78A.50001@yahoo.com> <46759AD3.2060209@yahoo.com> Message-ID: Hmm dead code. Is it valid to do that in Ruby, i.e. if the parse tree below you is empty dont execute the function call? On 6/18/07, Peter K Chan wrote: > > Nate, > "Slow" is a relative term. JNI is fast enough for most > perception, but it is still marshalling calls across the JVM boundary. > In general, if you do intensive benchmarking, then pure Java method call > inside the JVM is going to be faster than JNI call across JVM/JNI > boundary. > > I took a look at the code that you posted, and I have two > observations: > > test_controller_test.rb (rjb) > - I am not sure what is being benchmark in this file. Correct me if I am > wrong, but it looks like the code is only calling the Java method *once* > using RJB (presumably with JNI), but then the bulk of the execution is > done inside the JVM with Java code. In other words, it looks like a > benchmark of the Java code performance, rather than a benchmark of > RJB->Java invocation performance. The same seems to be true with the > hanoi_jruby.rb, which also seems to make just one call into the Java > method from JRuby. > > Hanoi.java > - The move method has an empty body, which would have been optimized > away by the Hotspot JIT as dead code. So, the result may have been > skewed toward Java's favor, since the JVM is smart enough to skip the > move(char, char) completely, whereas C Ruby would still make that method > dispatch. By my own quick test, the empty body ran in 1.8s, where as > adding a Class.staticField++ statement increases the execution time to > 2.3s (careful, you can't just increment the local variable, hotspot will > still spot the lack of effect and optimize that away). This optimization > only shows up in the server VM though. > > I am sure that Java is faster anyway, but in this case, it is also > smarter and cheated. :) The problem with benchmarking with Hotspot is > that it is so smart, you have to work hard to make sure that your code > is actually still executed. > > Peter > > -----Original Message----- > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > Sent: Sunday, June 17, 2007 3:34 PM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > Peter K Chan wrote: > > Nate, > > Thanks for reporting back with your findings. For the past few > months I have heard reports about how Java is approaching or even > exceeding C speed on certain algorithmic implementation. This could > explain why writing the Tower of Hanoi is so much faster in Java then > Ruby - the algorithm is probably well-optimized by the JVM just-in-time > compiler, and you are essentially comparing purely-interpreted Ruby > speed with native C speed. > > > This could be. > > Also, since JRuby runs inside the JVM, that would explain why it > is faster than RJB. I imagine that RJB is using Java Native Interface to > call Java code, which can be slow. > > > RHB does use JNI - but I have not experienced JNI as "slow" before. > > Can you post (or send me privately) the code that you used to > > benchmark? Reading from your email, it sounds like you did a bunch of > > test, but it wasn't very clear exactly what you tested for. (Hanoi in > > Java vs. Hanoi in C Ruby? Hanoi in C Ruby vs. Hanoi in JRuby? RJB vs. > > JRuby in invoking Java code?) > > > Attached to this email please find code samples. > > I don't think I have any more comments to add to this, but I > wouldn't mind taking a look at the code. > > > Blessings, > Nate > > Thanks, > > > > Peter > > > > From: chicagogroup-members-list-bounces at rubyforge.org > > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > > Nate Kirby > > Sent: Saturday, June 16, 2007 7:29 AM > > To: Chirb discussion list > > Subject: Re: [Chirb] JRuby performance > > > > Peter, > > > > I don't like eating crow, but it is better than starving. The current > > > results are (the I in this is not form me but a colleague) > > [Summation: Performance for CPU indicates JRuby is the way to go] > > > > ############################################### > > Here are the results: > > > > 1. Java is much faster than Ruby. Implementing the Hanoi algorithm in > > Java, either calling from JRuby or through RJB gains the hundreds of > > times of performance boost. At first I let the number of disks be 28, > > the same as last time I sent you, but this time only takes a few > > seconds. > > ---------------------------------------------------------------------- > > -------------- clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh > > > Loaded suite test/functional/test_controller_test > > Started > > Number of disks: 28 > > Start Time: 1181985788.69547 > > Finish Time: 1181985796.42535 > > Time used: 7.72987794876099 seconds > > . > > Finished in 7.808512 seconds. > > > > 1 tests, 0 assertions, 0 failures, 0 errors > > ---------------------------------------------------------------------- > > ------ clive at epiphany:~/Desktop/performance$ ./jruby.sh Number of > > disks: 28 Start Time: 1181984655.81 Finish Time: 1181984659.713 Time > > used: 3.9030001163482666 seconds > > ---------------------------------------------------------------------- > > ----------- > > > > 2. Since both only took a few seconds, I increased the number of disks > > > to gain more accurate results, and found that calling Java code from > > JRuby is faster than calling through RJB: > > ---------------------------------------------------------------------- > > --------- clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh > > Loaded suite test/functional/test_controller_test > > Started > > Number of disks: 35 > > Start Time: 1181985899.15607 > > Finish Time: 1181986895.74254 > > Time used: 996.586473941803 seconds > > . > > Finished in 996.662218 seconds. > > ---------------------------------------------------------------------- > > --------- clive at epiphany:~/Desktop/performance$ ./jruby.sh Number of > > disks: 35 Start Time: 1181988594.084 Finish Time: 1181989376.494 Time > > used: 782.4099998474121 seconds > > ---------------------------------------------------------------------- > > -------------- > > A few notes: > > 1. I don't know how to use RJB in ruby without rails, so I created a > > rails project and wrote a functional test to host those code. The > > rjb.sh in the zip file is what I used to run the test. I used Java > > server VM to run the Java code. I wonder if there are more things to > > do to tune the performance of RJB. > > 2. For JRuby, I used all performance tuning methods I used last time, > > plus this time I used Java server VM. This can be seen in jruby.sh 3. > > hanoi.zip is the Java code I used. I have trouble in passing arguments > > > of primitive types to Java, both in rjb and jruby, so I overloaded the > > > method with arguments of classes. But in terms of performance > > comparison, I don't think that matters. > > ############################################## > > > > Needless to say we are investigation JRuby seriously now. If you want > the source for these tests I can provide it. > > > > Blessing, > > Nate > > > > > > > > > > Peter K Chan wrote: > > Nate, > > Thanks for getting back to me. I haven't seen the source for > your > > benchmark, but I imagine that it may be doing some specific processing > > > that JRuby is slow at (i.e. looking at the method names, it seems to > > be doing quite a bit of byte shuffling?). > > > > Also, just a guess, but the 8x difference worsening to 14x times > may > > be due to JVM startup cost (a real possibility; once you step into > > single digit second run time). > > > > In any case, here is a link which explains how to tune JRuby for > > > performance, including how to disable Object Space and turn on > compiler: > > > > http://www.headius.com/jrubywiki/index.php/Performance_Tuning > > > > Just to put things in context: JRuby shines when you are doing > > integration with Java and long running server processes. One time > > scripts may still be a sore point for the foreseeable future, simply > > because of the JVM start-up and warm-up cost. > > > > Peter > > > > -----Original Message----- > > From: chicagogroup-members-list-bounces at rubyforge.org > > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > > Nate Kirby > > Sent: Wednesday, May 30, 2007 9:10 AM > > To: Chirb discussion list > > Subject: Re: [Chirb] JRuby performance > > > > Peter, > > > > This is the reponse I got: > > > > ************* > > The JVM on my Ubuntu machine is Sun's: > > > > clive at epiphany:~$ java -version > > java version "1.6.0" > > Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) > > Client VM (build 1.6.0-b105, mixed mode, sharing) > > > > And I use the latest version of JRuby. I ran that piece of code with > > profiling again on my machine, which is very old one, C Ruby took 2.72 > > > sec, JRuby took 22.78 sec. 8.375 times difference. > > Then I changed the code, took out profiler, and printed out the start > > time and finish time only, C Ruby took 0.27586 sec, JRuby took 4.074 > > sec: 14.768360763 times difference. > > > > The attachment is the raw data. I did not: > > -disable object space (I did some research, but have no idea of how to > > > do that. The hotspot server seemed to have some option about size of > > object space, but I don't think it allows us to set the size to 0) > > > > -turn on the JRuby AOT or JIT compiler ( I have no idea of what that > > is) > > > > It seems that the performance under default setting is still bad. > > > > ************** > > Blessings, > > Nate > > > > Peter K Chan wrote: > > > > Sure, Nate. > > > > I do concede that JRuby is not yet a Ruby drop in replacement, at > > > > least not for running small scripts. It takes only 5 minutes to tweak > > the performance, but it is still 5 minutes more than C Ruby. Where > > JRuby really shines is in Java integration and scalability (e.g. > > running multiple rails instances within a single JVM, connecting to a > > JDBC database). > > > > I would be very interested in seeing what kind of performance you get > > > > for your evaluation. > > > > Peter > > ________________________________________ > > From: chicagogroup-members-list-bounces at rubyforge.org > > > > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > > Nate Kirby > > > > Sent: Tuesday, May 29, 2007 7:32 PM > > To: Chirb discussion list > > Subject: Re: [Chirb] JRuby performance > > > > Peter, > > > > I actually had someone else do it. I will forward your suggestions > > > > along to them. I have had the impression in the past that individual > > vendors VMs were often faster than Suns for their platform. That is > > possibly in error, but in the late 90's it was not. > > > > Thanks, > > Nate > > > > Peter K Chan wrote: > > Nate, > > Josh has already brought up most of what I was going to reply to > > > > you, but let me just highlight these factors, which may explain your > > performance result: > > > > - Are you using a modern JVM, such as Sun 1.6.0, with hotspot/JIT > > > > compilation? > > > > - Did you disable object space? (Makes a huge 20% - 40% difference, I > > > > disable it in all my apps) > > > > - Did you pull the latest trunk or at least RC version of JRuby? > > - Did you turn on the JRuby AOT or JIT compiler? > > - I think that JRuby's set_trace_func is slow; therefore, if you use > > > > profile.rb, you may be incurring large profiling cost (actually, > > set_trace_func isn't working in current JRuby compiler, so you must > > have been running JRuby in pure interpretive mode). > > > > > > Also, keep in mind that the benchmark result I linked to > > > > include JVM startup time. If you consider that the JVM takes a few > > seconds to fully warm up, and most benchmark finishes in a few > > seconds, JRuby's result is even more impressive. > > > > Don't take my word for it. Run your benchmark with the right > > > > settings, and you can see for yourself. :) > > > > Peter > > ________________________________________ > > From: chicagogroup-members-list-bounces at rubyforge.org > > > > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > > Josh Cronemeyer > > > > Sent: Tuesday, May 29, 2007 11:11 AM > > To: Chirb discussion list > > Subject: [Chirb] JRuby performance > > > > > > discussion moved from this thread: Re: [Chirb] time to rsvp for the > > > > mystery meeting! W00t > > > > Nate, > > > > I've heard alot of good stuff about jruby performance, not from just > > > > peter. > > > > > > [programmer at Mark ~]$ java --version > > java version "1.4.2" > > gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) > > > > I think you should run your tests with a real JVM (like sun's > > > > implementation). You are using gij which is a java interpretor. GIJ > > is a part of the GCJ project. GCJ is a very different beast than > > sun's implementation. The idea behind GCJ is that java is compiled > > down to your specific platform's machine code. So they bypass the jvm > > > all together. This sounds like it would be faster, but it really > > isn't for many things because sun's just in time compilation can > > actually compile the same code in different ways depending on context > > in order to optimize execution. I'm not sure if Jruby uses runtime > > code loading or generation (i wouldn't be surprised though). If that > > is the case GCJ is SUPER slow for those types of operations because > > that is when the gij interpreter kicks in. The interpreter is > realizing no benefits from > > optimization or compilation. > > > > The short of it: I wouldn't call my tests definitive until I was using > > > > sun's jvm. > > > > Josh Cronemeyer > > > > chicagogroup-members-list-bounces at rubyforge.org wrote on 05/29/2007 > > > > 04:20:56 AM: > > > > > > Peter, > > > > I can take your word for it....or I can check the performance stats we > > > just did a few weeks ago JRuby was 10x slower than ruby at the command > > > line on a Fedora box. > > > > Nate > > > > STATS > > > > [programmer at Mark ~]$ java --version > > java version "1.4.2" > > gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) > > > > Copyright (C) 2006 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There > > > > is NO > > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > > > PURPOSE. > > > > I did not change the default JVM. I used the Ruby project > > concatenating wav files and profiler to see the performance data. This > > > is the result: > > Ruby: > > % cumulative self self total > > time seconds seconds calls ms/call ms/call name > > 10.24 0.13 0.13 238 0.55 1.13 > > > > MonitorMixin.mon_exit > > > > 7.09 0.22 0.09 238 0.38 2.27 > > > > MonitorMixin.synchronize > > > > 6.30 0.30 0.08 238 0.34 3.57 Logger#add > > 5.51 0.37 0.07 238 0.29 0.34 Logger:: > > Formatter#format_datetime > > 4.72 0.43 0.06 17 3.53 68.82 FileFormat:: > > WavFile#getInfo > > 4.72 0.49 0.06 203 0.30 0.69 Integer#times > > 3.94 0.54 0.05 238 0.21 0.42 Logger:: > > LogDevice#check_shift_log > > 3.15 0.58 0.04 238 0.17 0.25 > > > > MonitorMixin.mon_release > > > > 3.15 0.62 0.04 238 0.17 0.34 > > > > MonitorMixin.mon_enter > > > > 2.36 0.65 0.03 256 0.12 0.12 String#+ > > 2.36 0.68 0.03 87 0.34 0.57 FileFormat:: > > WavFile#dataPos > > 2.36 0.71 0.03 177 0.17 0.85 FileFormat:: > > WavFile#readBigNum > > 2.36 0.74 0.03 530 0.06 0.06 IO#getc > > 2.36 0.77 0.03 8 3.75 155.00 Array#each > > 2.36 0.80 0.03 476 0.06 0.06 Thread#current > > 2.36 0.83 0.03 238 0.13 0.13 > > > > Logger#format_severity > > > > 2.36 0.86 0.03 238 0.13 0.21 MonitorMixin. > > mon_check_owner > > 2.36 0.89 0.03 952 0.03 0.03 Thread#critical= > > 2.36 0.92 0.03 238 0.13 0.55 > > > > Logger::Formatter#call > > > > 1.57 0.94 0.02 476 0.04 0.04 Array#shift > > 1.57 0.96 0.02 1060 0.02 0.02 Fixnum#* > > 1.57 0.98 0.02 238 0.08 0.08 Module#=== > > 1.57 1.00 0.02 238 0.08 0.08 IO#stat > > 1.57 1.02 0.02 87 0.23 0.23 IO#readline > > 1.57 1.04 0.02 476 0.04 0.04 Fixnum#> > > 1.57 1.06 0.02 965 0.02 0.02 Fixnum#+ > > 0.79 1.07 0.01 17 0.59 2.94 FileFormat:: > > WavFile#extraParams > > 0.79 1.08 0.01 238 0.04 0.04 Kernel.nil? > > 0.79 1.09 0.01 240 0.04 0.04 Time#initialize > > 0.79 1.10 0.01 44 0.23 0.23 IO#putc > > 0.79 1.11 0.01 34 0.29 0.29 FileFormat:: > > WavFile#fileSize > > 0.79 1.12 0.01 238 0.04 0.59 > > > > Logger#format_message > > > > 0.79 1.13 0.01 34 0.29 0.29 IO#read > > 0.79 1.14 0.01 17 0.59 0.59 FileFormat:: > > WavFile#readBytes > > 0.79 1.15 0.01 238 0.04 0.04 Time#usec > > 0.79 1.16 0.01 238 0.04 0.04 > > > > Kernel.block_given? > > > > 0.79 1.17 0.01 238 0.04 2.31 > > > > Logger::LogDevice#write > > > > 0.79 1.18 0.01 18 0.56 0.56 FileFormat:: > > WavFile#bitPerSample > > 0.79 1.19 0.01 34 0.29 1.47 FileFormat:: > > WavFile#subChunk2Size > > 0.79 1.20 0.01 238 0.04 0.13 > > > > MonitorMixin.mon_acquire > > > > 0.79 1.21 0.01 238 0.04 0.04 Fixnum#< > > 0.79 1.22 0.01 238 0.04 3.61 Logger#info > > 0.79 1.23 0.01 18 0.56 1.67 FileFormat:: > > WavFile#sampleRate > > 0.79 1.24 0.01 325 0.03 0.03 Kernel.== > > 0.79 1.25 0.01 238 0.04 0.04 File::Stat#size > > 0.79 1.26 0.01 240 0.04 0.08 Time#now > > 0.79 1.27 0.01 344 0.03 0.03 Fixnum#== > > 0.00 1.27 0.00 2 0.00 0.00 IO#sync= > > 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: > > WavFile#byteRate > > 0.00 1.27 0.00 18 0.00 0.00 Class#new > > 0.00 1.27 0.00 17 0.00 0.00 Array#to_s > > 0.00 1.27 0.00 1 0.00 0.00 FileFormat:: > > FileConcat#initialize > > 0.00 1.27 0.00 18 0.00 0.00 IO#to_io > > 0.00 1.27 0.00 35 0.00 0.00 FileFormat:: > > WavFile#audioFormat > > 0.00 1.27 0.00 238 0.00 0.08 > > > > Logger::Formatter#msg2str > > > > 0.00 1.27 0.00 238 0.00 0.00 String#[] > > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > > WavFile#openFile > > 0.00 1.27 0.00 28 0.00 0.00 Fixnum#<< > > 0.00 1.27 0.00 56 0.00 0.00 Fixnum#>> > > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > > LogDevice#create_logfile > > 0.00 1.27 0.00 298 0.00 0.00 IO#pos= > > 0.00 1.27 0.00 17 0.00 0.00 File#exist? > > 0.00 1.27 0.00 238 0.00 0.00 Thread#pass > > 0.00 1.27 0.00 238 0.00 0.00 NilClass#to_s > > 0.00 1.27 0.00 17 0.00 0.00 Array#<< > > 0.00 1.27 0.00 51 0.00 0.00 IO#eof? > > 0.00 1.27 0.00 9 0.00 2.22 FileFormat:: > > FileConcat#writeData > > 0.00 1.27 0.00 2 0.00 0.00 Time#to_s > > 0.00 1.27 0.00 17 0.00 0.00 > > > > FileFormat::WavFile#exist? > > > > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > > WavFile#chunkSize > > 0.00 1.27 0.00 238 0.00 0.00 > > > > Kernel.respond_to? > > > > 0.00 1.27 0.00 1 0.00 0.00 IO#new > > 0.00 1.27 0.00 238 0.00 0.00 Time#strftime > > 0.00 1.27 0.00 4 0.00 0.00 Fixnum#| > > 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: > > WavFile#blockAlign > > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > > WavFile#extraParamSize > > 0.00 1.27 0.00 6 0.00 0.00 FileTest.exist? > > 0.00 1.27 0.00 17 0.00 0.00 IO#open > > 0.00 1.27 0.00 355 0.00 0.00 Fixnum#- > > 0.00 1.27 0.00 239 0.00 0.00 Array#[] > > 0.00 1.27 0.00 18 0.00 1.67 FileFormat:: > > WavFile#numChannels > > 0.00 1.27 0.00 1 0.00 0.00 Array#size > > 0.00 1.27 0.00 20 0.00 0.00 IO#close > > 0.00 1.27 0.00 8 0.00 0.00 File#rename > > 0.00 1.27 0.00 87 0.00 0.00 String#index > > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > > WavFile#initialize > > 0.00 1.27 0.00 1 0.00 90.00 FileFormat:: > > FileConcat#concatFiles > > 0.00 1.27 0.00 2 0.00 0.00 Kernel.open > > 0.00 1.27 0.00 2 0.00 0.00 Integer#downto > > 0.00 1.27 0.00 4 0.00 0.00 FileFormat:: > > FileConcat#writeBytes > > 0.00 1.27 0.00 1 0.00 30.00 FileFormat:: > > FileConcat#concat_data_block > > 0.00 1.27 0.00 476 0.00 0.00 NilClass#nil? > > 0.00 1.27 0.00 20 0.00 0.00 File#initialize > > 0.00 1.27 0.00 478 0.00 0.00 String#% > > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > > LogDevice#add_log_header > > 0.00 1.27 0.00 18 0.00 2.78 FileFormat:: > > WavFile#subChunk1Size > > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > > LogDevice#shift_log_age > > 0.00 1.27 0.00 318 0.00 0.00 IO#write > > 0.00 1.27 0.00 238 0.00 0.00 String#<< > > 0.00 1.27 0.00 238 0.00 0.00 Kernel.is_a? > > 0.00 1.27 0.00 222 0.00 0.00 Fixnum#to_s > > 0.00 1.27 0.00 34 0.00 0.00 File#size > > 0.00 1.27 0.00 1 0.00 1270.00 #toplevel > > > > JRuby: > > % cumulative self self total > > time seconds seconds calls ms/call ms/call name > > 10.27 1.25 1.25 203 6.17 7.84 Integer#times > > 9.64 2.43 1.17 238 4.94 36.55 Logger#add > > 6.57 3.23 0.80 238 3.37 5.86 > > > > MonitorMixin.mon_exit > > > > 5.23 3.86 0.64 238 2.68 4.19 Logger:: > > Formatter#format_datetime > > 4.92 4.46 0.60 238 2.52 19.33 MonitorMixin. > > mon_synchronize > > 4.37 5.00 0.53 274 1.95 1.95 IO#write > > 4.12 5.50 0.50 238 2.11 5.62 Logger:: > > LogDevice#check_shift_log > > 3.36 5.91 0.41 238 1.72 3.01 > > > > MonitorMixin.mon_enter > > > > 3.23 6.30 0.39 497 0.79 1.52 Class#new > > 3.08 6.68 0.38 238 1.58 1.65 > > > > Logger::Formatter#msg2str > > > > 2.33 6.96 0.28 238 1.19 1.62 > > > > Logger#format_severity > > > > 2.33 7.24 0.28 238 1.19 37.75 Logger#info > > 2.21 7.51 0.27 238 1.13 7.65 > > > > Logger::Formatter#call > > > > 2.18 7.78 0.27 238 1.12 1.12 > > > > File::Stat#initialize > > > > 2.08 8.03 0.25 17 14.94 658.12 FileFormat:: > > WavFile#getInfo > > 1.71 8.24 0.21 238 0.88 1.00 > > > > MonitorMixin.mon_acquire > > > > 1.70 8.45 0.21 87 2.38 4.87 FileFormat:: > > WavFile#dataPos > > 1.62 8.65 0.20 177 1.12 10.50 FileFormat:: > > WavFile#readBigNum > > 1.51 8.83 0.18 478 0.38 0.55 String#% > > 1.44 9.01 0.18 238 0.74 8.39 > > > > Logger#format_message > > > > 1.40 9.18 0.17 476 0.36 0.36 NilClass#nil? > > 1.37 9.35 0.17 238 0.70 1.08 > > > > MonitorMixin.mon_release > > > > 1.32 9.51 0.16 238 0.68 0.68 Time#strftime > > 1.31 9.67 0.16 298 0.54 0.54 IO#pos= > > 1.23 9.82 0.15 915 0.16 0.16 > > > > FileFormat::WavFile#file > > > > 1.19 9.96 0.15 238 0.61 19.94 > > > > Logger::LogDevice#write > > > > 1.10 10.10 0.13 952 0.14 0.14 > > > > ##critical= > > > > 1.00 10.22 0.12 238 0.51 0.80 MonitorMixin. > > mon_check_owner > > 0.91 10.33 0.11 530 0.21 0.21 IO#getc > > 0.85 10.43 0.10 238 0.43 0.43 Kernel.is_a? > > 0.85 10.54 0.10 1060 0.10 0.10 Fixnum#* > > 0.83 10.64 0.10 239 0.42 0.42 Array#[] > > 0.81 10.74 0.10 476 0.21 0.21 Fixnum#> > > 0.75 10.83 0.09 476 0.19 0.19 Array#shift > > 0.72 10.91 0.09 965 0.09 0.09 Fixnum#+ > > 0.71 11.00 0.09 8 10.75 1494.63 Array#each > > 0.71 11.09 0.09 34 2.53 2.53 IO#read > > 0.66 11.17 0.08 238 0.34 2.50 File#stat > > 0.66 11.25 0.08 238 0.34 0.34 Time#usec > > 0.64 11.33 0.08 238 0.33 0.33 NilClass#to_s > > 0.62 11.40 0.08 238 0.32 0.32 > > > > Kernel.respond_to? > > > > 0.61 11.47 0.07 35 2.11 11.74 FileFormat:: > > WavFile#audioFormat > > 0.57 11.54 0.07 344 0.20 0.21 Fixnum#== > > 0.51 11.61 0.06 476 0.13 0.13 > > > > ##current > > > > 0.40 11.65 0.05 238 0.21 0.21 Fixnum#< > > 0.33 11.69 0.04 325 0.12 0.12 Kernel.== > > 0.32 11.73 0.04 17 2.29 5.71 > > > > FileFormat::WavFile#exist? > > > > 0.25 11.76 0.03 1 31.00 31.00 File#initialize > > 0.25 11.79 0.03 222 0.14 0.14 Fixnum#to_s > > 0.24 11.82 0.03 85 0.34 0.34 FileFormat:: > > WavFile#fileDir > > 0.21 11.85 0.02 238 0.11 0.11 > > > > Kernel.block_given? > > > > 0.20 11.87 0.02 240 0.10 0.10 Time#initialize > > 0.19 11.90 0.02 17 1.35 1.71 FileFormat:: > > WavFile#readBytes > > 0.19 11.92 0.02 238 0.10 0.10 > > > > ##pass > > > > 0.17 11.94 0.02 17 1.24 16.71 FileFormat:: > > WavFile#extraParamSize > > 0.15 11.96 0.02 17 1.06 1.94 FileFormat:: > > WavFile#openFile > > 0.15 11.98 0.02 238 0.08 0.08 Module#=== > > 0.14 11.99 0.02 355 0.05 0.05 Fixnum#- > > 0.13 12.01 0.02 34 0.47 23.35 FileFormat:: > > WavFile#subChunk2Size > > 0.13 12.02 0.02 87 0.18 0.18 IO#readline > > 0.10 12.04 0.01 18 0.67 16.67 FileFormat:: > > WavFile#bitPerSample > > 0.10 12.05 0.01 238 0.05 0.05 File::Stat#size > > 0.09 12.06 0.01 238 0.05 0.05 Kernel.nil? > > 0.08 12.07 0.01 1 10.00 801.00 FileFormat:: > > FileConcat#concatFiles > > 0.08 12.08 0.01 17 0.59 0.59 FileFormat:: > > WavFile#initialize > > 0.07 12.09 0.01 17 0.53 0.53 > > > > ##open > > > > 0.07 12.10 0.01 34 0.26 0.38 FileFormat:: > > WavFile#fileSize > > 0.07 12.11 0.01 18 0.44 5.67 FileFormat:: > > WavFile#sampleRate > > 0.07 12.11 0.01 87 0.09 0.09 String#index > > 0.05 12.12 0.01 9 0.67 4.78 FileFormat:: > > FileConcat#writeData > > 0.05 12.12 0.01 17 0.35 0.35 FileTest.exist? > > 0.04 12.13 0.01 2 2.50 8.00 Integer#downto > > 0.04 12.14 0.01 18 0.28 6.17 FileFormat:: > > WavFile#subChunk1Size > > 0.04 12.14 0.01 18 0.28 4.67 FileFormat:: > > WavFile#blockAlign > > 0.04 12.15 0.00 17 0.29 0.71 FileFormat:: > > WavFile#chunkSize > > 0.04 12.15 0.00 18 0.28 12.22 FileFormat:: > > WavFile#byteRate > > 0.03 12.15 0.00 34 0.12 0.12 FileTest.size > > 0.03 12.16 0.00 44 0.09 0.09 IO#putc > > 0.03 12.16 0.00 18 0.22 0.22 IO#to_io > > 0.02 12.17 0.00 17 0.18 5.82 FileFormat:: > > WavFile#extraParams > > 0.02 12.17 0.00 2 1.50 3.50 Logger:: > > LogDevice#create_logfile > > 0.02 12.17 0.00 20 0.15 0.15 IO#close > > 0.02 12.17 0.00 17 0.12 0.12 Array#<< > > 0.02 12.18 0.00 8 0.25 0.25 > > > > ##rename > > > > 0.02 12.18 0.00 28 0.07 0.07 Fixnum#<< > > 0.02 12.18 0.00 56 0.04 0.04 Fixnum#>> > > 0.02 12.18 0.00 18 0.11 8.94 FileFormat:: > > WavFile#numChannels > > 0.02 12.18 0.00 51 0.04 0.04 IO#eof > > 0.01 12.18 0.00 2 0.50 2.00 Logger:: > > LogDevice#add_log_header > > 0.01 12.18 0.00 2 0.50 0.50 Time#to_s > > 0.00 12.18 0.00 2 0.00 0.00 IO#sync= > > 0.00 12.18 0.00 2 0.00 12.50 Logger:: > > LogDevice#shift_log_age > > 0.00 12.18 0.00 6 0.00 0.00 > > > > ##exist? > > > > 0.00 12.18 0.00 1 0.00 0.00 Array#length > > 0.00 12.18 0.00 2 0.00 0.00 Kernel.open > > 0.00 12.18 0.00 1 0.00 31.00 FileFormat:: > > FileConcat#initialize > > 0.00 12.18 0.00 17 0.00 0.00 Array#to_s > > 0.00 12.18 0.00 1 0.00 209.00 FileFormat:: > > FileConcat#concat_data_block > > 0.00 12.18 0.00 4 0.00 0.00 Fixnum#| > > 0.00 12.18 0.00 4 0.00 1.00 FileFormat:: > > FileConcat#writeBytes > > 0.00 12.19 0.00 1 0.00 12187.00 #toplevel > > > > This performance of JRuby is rather bad. Reasons may come from: > > 1. JRuby is in nature very slow. We can not do anything to this 2. > > JRuby's startup time is longer than that of Ruby. I wonder this > > situation would be improved if we have had on in-memory JVM > > > > > > Peter K Chan wrote: > > Not anymore, Nate. :) > > > > JRuby WAS slow six months ago, but it has come a long way. Check this > > > > out: > > > > > > > > > http://headius.blogspot.com/2007/04/paving-road-to-jruby-10-performance. > > html > > > > Summary: In interpretive mode, JRuby is no more than 2x slower, and > > that's including JVM startup and lack of hotspot warm up. In > > unoptimized compiled mode, JRuby often beats C Ruby. I have been using > > > JRuby in my project, and I haven't had any performance complaints > > since 2 months ago. > > > > Peter > > ________________________________________ > > From: chicagogroup-members-list-bounces at rubyforge.org [mailto: > > chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Nate > > > > Kirby > > > > Sent: Tuesday, May 29, 2007 2:23 AM > > To: Chirb discussion list > > Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t > > > > Peter, > > > > JRuby is slow. Try RJB (http://rjb.rubyforge.org/) > > > > Nate > > > > Peter K Chan wrote: > > Sure! I will be up for some Uger-hacking/feedback-taking (I also need > > > > to > > > > apply Colin's patch from a while ago and push it out). > > > > Hmm...maybe I should think of a lightning talk on JRuby or something. > > > > Peter > > > > -----Original Message----- > > From: chicagogroup-members-list-bounces at rubyforge.org > > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > > Evan Farrar > > Sent: Monday, May 28, 2007 5:51 PM > > To: Chirb discussion list > > Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t > > > > Woohoo Lightning talks! I will definitely come with something. I also > > would like to call together a uger hacksession if Peter Chang is > > around for the meeting. > > > > On 5/28/07, Josh Cronemeyer wrote: > > > > Ok, nobody signed up for the talk and we are a week away from the next > > > CHIRB. Soooo, unless anyone objects I think we should have another > > "lightning talk / code pit" session like the one last december. If > > > > you can > > > > prepare something that you can get through in 10 minutes or so, please > > > > do. > > > > Alternatively you can put out a request for a talk on a certain topic > > > > and > > > > perhaps that will inspire somebody. I'm mulling over a topic just to > > > > force > > > > myself to learn something new (Why's camping framework). But I make > > > > no > > > > promises :) Let's have fun with this and take advantage of the chance > > > > for > > > > all of us to talk. No pressure!!!! > > > > http://chirb.org/event/show/18 > > > > Josh Cronemeyer > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > > > > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/88426aae/attachment-0001.html From peter at oaktop.com Mon Jun 18 14:25:46 2007 From: peter at oaktop.com (Peter K Chan) Date: Mon, 18 Jun 2007 14:25:46 -0400 Subject: [Chirb] JRuby performance In-Reply-To: References: <465BF078.8050808@yahoo.com><465CC5FD.7030505@yahoo.com><465D85AD.3010700@yahoo.com><4673D78A.50001@yahoo.com><46759AD3.2060209@yahoo.com> Message-ID: Well, probably. As long as the trace function is fired properly. Note that I was referring to the Java version of the move(char, char) method. I doubt either C Ruby or JRuby optimize away any Ruby dead code at this point. Peter From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Mark Alexander Friedgan Sent: Monday, June 18, 2007 1:14 PM To: Chirb discussion list Subject: Re: [Chirb] JRuby performance Hmm dead code. Is it valid to do that in Ruby, i.e. if the parse tree below you is empty dont execute the function call? On 6/18/07, Peter K Chan < peter at oaktop.com > wrote: Nate, "Slow" is a relative term. JNI is fast enough for most perception, but it is still marshalling calls across the JVM boundary. In general, if you do intensive benchmarking, then pure Java method call inside the JVM is going to be faster than JNI call across JVM/JNI boundary. I took a look at the code that you posted, and I have two observations: test_controller_test.rb (rjb) - I am not sure what is being benchmark in this file. Correct me if I am wrong, but it looks like the code is only calling the Java method *once* using RJB (presumably with JNI), but then the bulk of the execution is done inside the JVM with Java code. In other words, it looks like a benchmark of the Java code performance, rather than a benchmark of RJB->Java invocation performance. The same seems to be true with the hanoi_jruby.rb, which also seems to make just one call into the Java method from JRuby. Hanoi.java - The move method has an empty body, which would have been optimized away by the Hotspot JIT as dead code. So, the result may have been skewed toward Java's favor, since the JVM is smart enough to skip the move(char, char) completely, whereas C Ruby would still make that method dispatch. By my own quick test, the empty body ran in 1.8s, where as adding a Class.staticField++ statement increases the execution time to 2.3s (careful, you can't just increment the local variable, hotspot will still spot the lack of effect and optimize that away). This optimization only shows up in the server VM though. I am sure that Java is faster anyway, but in this case, it is also smarter and cheated. :) The problem with benchmarking with Hotspot is that it is so smart, you have to work hard to make sure that your code is actually still executed. Peter -----Original Message----- From: chicagogroup-members-list-bounces at rubyforge.org [mailto: chicagogroup-members-list-bounces at rubyforge.org ] On Behalf Of Nate Kirby Sent: Sunday, June 17, 2007 3:34 PM To: Chirb discussion list Subject: Re: [Chirb] JRuby performance Peter, Peter K Chan wrote: > Nate, > Thanks for reporting back with your findings. For the past few months I have heard reports about how Java is approaching or even exceeding C speed on certain algorithmic implementation. This could explain why writing the Tower of Hanoi is so much faster in Java then Ruby - the algorithm is probably well-optimized by the JVM just-in-time compiler, and you are essentially comparing purely-interpreted Ruby speed with native C speed. > This could be. > Also, since JRuby runs inside the JVM, that would explain why it is faster than RJB. I imagine that RJB is using Java Native Interface to call Java code, which can be slow. > RHB does use JNI - but I have not experienced JNI as "slow" before. > Can you post (or send me privately) the code that you used to > benchmark? Reading from your email, it sounds like you did a bunch of > test, but it wasn't very clear exactly what you tested for. (Hanoi in > Java vs. Hanoi in C Ruby? Hanoi in C Ruby vs. Hanoi in JRuby? RJB vs. > JRuby in invoking Java code?) > Attached to this email please find code samples. > I don't think I have any more comments to add to this, but I wouldn't mind taking a look at the code. > Blessings, Nate > Thanks, > > Peter > > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > Sent: Saturday, June 16, 2007 7:29 AM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > I don't like eating crow, but it is better than starving. The current > results are (the I in this is not form me but a colleague) > [Summation: Performance for CPU indicates JRuby is the way to go] > > ############################################### > Here are the results: > > 1. Java is much faster than Ruby. Implementing the Hanoi algorithm in > Java, either calling from JRuby or through RJB gains the hundreds of > times of performance boost. At first I let the number of disks be 28, > the same as last time I sent you, but this time only takes a few > seconds. > ---------------------------------------------------------------------- > -------------- clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh > Loaded suite test/functional/test_controller_test > Started > Number of disks: 28 > Start Time: 1181985788.69547 > Finish Time: 1181985796.42535 > Time used: 7.72987794876099 seconds > . > Finished in 7.808512 seconds. > > 1 tests, 0 assertions, 0 failures, 0 errors > ---------------------------------------------------------------------- > ------ clive at epiphany:~/Desktop/performance$ ./jruby.sh Number of > disks: 28 Start Time: 1181984655.81 Finish Time: 1181984659.713 Time > used: 3.9030001163482666 seconds > ---------------------------------------------------------------------- > ----------- > > 2. Since both only took a few seconds, I increased the number of disks > to gain more accurate results, and found that calling Java code from > JRuby is faster than calling through RJB: > ---------------------------------------------------------------------- > --------- clive at epiphany:~/Desktop/performance/rjb_test$ ./rjb.sh > Loaded suite test/functional/test_controller_test > Started > Number of disks: 35 > Start Time: 1181985899.15607 > Finish Time: 1181986895.74254 > Time used: 996.586473941803 seconds > . > Finished in 996.662218 seconds. > ---------------------------------------------------------------------- > --------- clive at epiphany :~/Desktop/performance$ ./jruby.sh Number of > disks: 35 Start Time: 1181988594.084 Finish Time: 1181989376.494 Time > used: 782.4099998474121 seconds > ---------------------------------------------------------------------- > -------------- > A few notes: > 1. I don't know how to use RJB in ruby without rails, so I created a > rails project and wrote a functional test to host those code. The > rjb.sh in the zip file is what I used to run the test. I used Java > server VM to run the Java code. I wonder if there are more things to > do to tune the performance of RJB. > 2. For JRuby, I used all performance tuning methods I used last time, > plus this time I used Java server VM. This can be seen in jruby.sh 3. > hanoi.zip is the Java code I used. I have trouble in passing arguments > of primitive types to Java, both in rjb and jruby, so I overloaded the > method with arguments of classes. But in terms of performance > comparison, I don't think that matters. > ############################################## > > Needless to say we are investigation JRuby seriously now. If you want the source for these tests I can provide it. > > Blessing, > Nate > > > > > Peter K Chan wrote: > Nate, > Thanks for getting back to me. I haven't seen the source for your > benchmark, but I imagine that it may be doing some specific processing > that JRuby is slow at (i.e. looking at the method names, it seems to > be doing quite a bit of byte shuffling?). > > Also, just a guess, but the 8x difference worsening to 14x times may > be due to JVM startup cost (a real possibility; once you step into > single digit second run time). > > In any case, here is a link which explains how to tune JRuby for > performance, including how to disable Object Space and turn on compiler: > > http://www.headius.com/jrubywiki/index.php/Performance_Tuning > > Just to put things in context: JRuby shines when you are doing > integration with Java and long running server processes. One time > scripts may still be a sore point for the foreseeable future, simply > because of the JVM start-up and warm-up cost. > > Peter > > -----Original Message----- > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto: chicagogroup-members-list-bounces at rubyforge.org ] On Behalf Of > Nate Kirby > Sent: Wednesday, May 30, 2007 9:10 AM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > This is the reponse I got: > > ************* > The JVM on my Ubuntu machine is Sun's: > > clive at epiphany:~$ java -version > java version "1.6.0" > Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) > Client VM (build 1.6.0-b105, mixed mode, sharing) > > And I use the latest version of JRuby. I ran that piece of code with > profiling again on my machine, which is very old one, C Ruby took 2.72 > sec, JRuby took 22.78 sec. 8.375 times difference. > Then I changed the code, took out profiler, and printed out the start > time and finish time only, C Ruby took 0.27586 sec, JRuby took 4.074 > sec: 14.768360763 times difference. > > The attachment is the raw data. I did not: > -disable object space (I did some research, but have no idea of how to > do that. The hotspot server seemed to have some option about size of > object space, but I don't think it allows us to set the size to 0) > > -turn on the JRuby AOT or JIT compiler ( I have no idea of what that > is) > > It seems that the performance under default setting is still bad. > > ************** > Blessings, > Nate > > Peter K Chan wrote: > > Sure, Nate. > > I do concede that JRuby is not yet a Ruby drop in replacement, at > > least not for running small scripts. It takes only 5 minutes to tweak > the performance, but it is still 5 minutes more than C Ruby. Where > JRuby really shines is in Java integration and scalability (e.g . > running multiple rails instances within a single JVM, connecting to a > JDBC database). > > I would be very interested in seeing what kind of performance you get > > for your evaluation. > > Peter > ________________________________________ > From: chicagogroup-members-list-bounces at rubyforge.org > > [mailto: chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of > Nate Kirby > > Sent: Tuesday, May 29, 2007 7:32 PM > To: Chirb discussion list > Subject: Re: [Chirb] JRuby performance > > Peter, > > I actually had someone else do it. I will forward your suggestions > > along to them. I have had the impression in the past that individual > vendors VMs were often faster than Suns for their platform. That is > possibly in error, but in the late 90's it was not. > > Thanks, > Nate > > Peter K Chan wrote: > Nate, > Josh has already brought up most of what I was going to reply to > > you, but let me just highlight these factors, which may explain your > performance result: > > - Are you using a modern JVM, such as Sun 1.6.0, with hotspot/JIT > > compilation? > > - Did you disable object space? (Makes a huge 20% - 40% difference, I > > disable it in all my apps) > > - Did you pull the latest trunk or at least RC version of JRuby? > - Did you turn on the JRuby AOT or JIT compiler? > - I think that JRuby's set_trace_func is slow; therefore, if you use > > profile.rb, you may be incurring large profiling cost (actually, > set_trace_func isn't working in current JRuby compiler, so you must > have been running JRuby in pure interpretive mode). > > > Also, keep in mind that the benchmark result I linked to > > include JVM startup time. If you consider that the JVM takes a few > seconds to fully warm up, and most benchmark finishes in a few > seconds, JRuby's result is even more impressive. > > Don't take my word for it. Run your benchmark with the right > > settings, and you can see for yourself. :) > > Peter > ________________________________________ > From: chicagogroup-members-list-bounces at rubyforge.org > > [mailto:chicagogroup-members-list-bounces at rubyforge.org ] On Behalf Of > Josh Cronemeyer > > Sent: Tuesday, May 29, 2007 11:11 AM > To: Chirb discussion list > Subject: [Chirb] JRuby performance > > > discussion moved from this thread: Re: [Chirb] time to rsvp for the > > mystery meeting! W00t > > Nate, > > I've heard alot of good stuff about jruby performance, not from just > > peter. > > > [programmer at Mark ~]$ java --version > java version "1.4.2" > gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) > > I think you should run your tests with a real JVM (like sun's > > implementation). You are using gij which is a java interpretor. GIJ > is a part of the GCJ project. GCJ is a very different beast than > sun's implementation. The idea behind GCJ is that java is compiled > down to your specific platform's machine code. So they bypass the jvm > all together. This sounds like it would be faster, but it really > isn't for many things because sun's just in time compilation can > actually compile the same code in different ways depending on context > in order to optimize execution. I'm not sure if Jruby uses runtime > code loading or generation (i wouldn't be surprised though). If that > is the case GCJ is SUPER slow for those types of operations because > that is when the gij interpreter kicks in. The interpreter is realizing no benefits from > optimization or compilation. > > The short of it: I wouldn't call my tests definitive until I was using > > sun's jvm. > > Josh Cronemeyer > > chicagogroup-members-list-bounces at rubyforge.org wrote on 05/29/2007 > > 04:20:56 AM: > > > Peter, > > I can take your word for it....or I can check the performance stats we > just did a few weeks ago JRuby was 10x slower than ruby at the command > line on a Fedora box. > > Nate > > STATS > > [programmer at Mark ~]$ java --version > java version "1.4.2" > gij (GNU libgcj) version 4.1.1 20070105 (Red Hat 4.1.1-51) > > Copyright (C) 2006 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There > > is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > PURPOSE. > > I did not change the default JVM. I used the Ruby project > concatenating wav files and profiler to see the performance data. This > is the result: > Ruby: > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 10.24 0.13 0.13 238 0.55 1.13 > > MonitorMixin.mon_exit > > 7.09 0.22 0.09 238 0.38 2.27 > > MonitorMixin.synchronize > > 6.30 0.30 0.08 238 0.34 3.57 Logger#add > 5.51 0.37 0.07 238 0.29 0.34 Logger:: > Formatter#format_datetime > 4.72 0.43 0.06 17 3.53 68.82 FileFormat:: > WavFile#getInfo > 4.72 0.49 0.06 203 0.30 0.69 Integer#times > 3.94 0.54 0.05 238 0.21 0.42 Logger:: > LogDevice#check_shift_log > 3.15 0.58 0.04 238 0.17 0.25 > > MonitorMixin.mon_release > > 3.15 0.62 0.04 238 0.17 0.34 > > MonitorMixin.mon_enter > > 2.36 0.65 0.03 256 0.12 0.12 String#+ > 2.36 0.68 0.03 87 0.34 0.57 FileFormat:: > WavFile#dataPos > 2.36 0.71 0.03 177 0.17 0.85 FileFormat:: > WavFile#readBigNum > 2.36 0.74 0.03 530 0.06 0.06 IO#getc > 2.36 0.77 0.03 8 3.75 155.00 Array#each > 2.36 0.80 0.03 476 0.06 0.06 Thread#current > 2.36 0.83 0.03 238 0.13 0.13 > > Logger#format_severity > > 2.36 0.86 0.03 238 0.13 0.21 MonitorMixin. > mon_check_owner > 2.36 0.89 0.03 952 0.03 0.03 Thread#critical= > 2.36 0.92 0.03 238 0.13 0.55 > > Logger::Formatter#call > > 1.57 0.94 0.02 476 0.04 0.04 Array#shift > 1.57 0.96 0.02 1060 0.02 0.02 Fixnum#* > 1.57 0.98 0.02 238 0.08 0.08 Module#=== > 1.57 1.00 0.02 238 0.08 0.08 IO#stat > 1.57 1.02 0.02 87 0.23 0.23 IO#readline > 1.57 1.04 0.02 476 0.04 0.04 Fixnum#> > 1.57 1.06 0.02 965 0.02 0.02 Fixnum#+ > 0.79 1.07 0.01 17 0.59 2.94 FileFormat:: > WavFile#extraParams > 0.79 1.08 0.01 238 0.04 0.04 Kernel.nil? > 0.79 1.09 0.01 240 0.04 0.04 Time#initialize > 0.79 1.10 0.01 44 0.23 0.23 IO#putc > 0.79 1.11 0.01 34 0.29 0.29 FileFormat:: > WavFile#fileSize > 0.79 1.12 0.01 238 0.04 0.59 > > Logger#format_message > > 0.79 1.13 0.01 34 0.29 0.29 IO#read > 0.79 1.14 0.01 17 0.59 0.59 FileFormat:: > WavFile#readBytes > 0.79 1.15 0.01 238 0.04 0.04 Time#usec > 0.79 1.16 0.01 238 0.04 0.04 > > Kernel.block_given? > > 0.79 1.17 0.01 238 0.04 2.31 > > Logger::LogDevice#write > > 0.79 1.18 0.01 18 0.56 0.56 FileFormat:: > WavFile#bitPerSample > 0.79 1.19 0.01 34 0.29 1.47 FileFormat:: > WavFile#subChunk2Size > 0.79 1.20 0.01 238 0.04 0.13 > > MonitorMixin.mon_acquire > > 0.79 1.21 0.01 238 0.04 0.04 Fixnum#< > 0.79 1.22 0.01 238 0.04 3.61 Logger#info > 0.79 1.23 0.01 18 0.56 1.67 FileFormat:: > WavFile#sampleRate > 0.79 1.24 0.01 325 0.03 0.03 Kernel.== > 0.79 1.25 0.01 238 0.04 0.04 File::Stat#size > 0.79 1.26 0.01 240 0.04 0.08 Time#now > 0.79 1.27 0.01 344 0.03 0.03 Fixnum#== > 0.00 1.27 0.00 2 0.00 0.00 IO#sync= > 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: > WavFile#byteRate > 0.00 1.27 0.00 18 0.00 0.00 Class#new > 0.00 1.27 0.00 17 0.00 0.00 Array#to_s > 0.00 1.27 0.00 1 0.00 0.00 FileFormat:: > FileConcat#initialize > 0.00 1.27 0.00 18 0.00 0.00 IO#to_io > 0.00 1.27 0.00 35 0.00 0.00 FileFormat:: > WavFile#audioFormat > 0.00 1.27 0.00 238 0.00 0.08 > > Logger::Formatter#msg2str > > 0.00 1.27 0.00 238 0.00 0.00 String#[] > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#openFile > 0.00 1.27 0.00 28 0.00 0.00 Fixnum#<< > 0.00 1.27 0.00 56 0.00 0.00 Fixnum#>> > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > LogDevice#create_logfile > 0.00 1.27 0.00 298 0.00 0.00 IO#pos= > 0.00 1.27 0.00 17 0.00 0.00 File#exist? > 0.00 1.27 0.00 238 0.00 0.00 Thread#pass > 0.00 1.27 0.00 238 0.00 0.00 NilClass#to_s > 0.00 1.27 0.00 17 0.00 0.00 Array#<< > 0.00 1.27 0.00 51 0.00 0.00 IO#eof? > 0.00 1.27 0.00 9 0.00 2.22 FileFormat:: > FileConcat#writeData > 0.00 1.27 0.00 2 0.00 0.00 Time#to_s > 0.00 1.27 0.00 17 0.00 0.00 > > FileFormat::WavFile#exist? > > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#chunkSize > 0.00 1.27 0.00 238 0.00 0.00 > > Kernel.respond_to? > > 0.00 1.27 0.00 1 0.00 0.00 IO#new > 0.00 1.27 0.00 238 0.00 0.00 Time#strftime > 0.00 1.27 0.00 4 0.00 0.00 Fixnum#| > 0.00 1.27 0.00 18 0.00 0.56 FileFormat:: > WavFile#blockAlign > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#extraParamSize > 0.00 1.27 0.00 6 0.00 0.00 FileTest.exist? > 0.00 1.27 0.00 17 0.00 0.00 IO#open > 0.00 1.27 0.00 355 0.00 0.00 Fixnum#- > 0.00 1.27 0.00 239 0.00 0.00 Array#[] > 0.00 1.27 0.00 18 0.00 1.67 FileFormat:: > WavFile#numChannels > 0.00 1.27 0.00 1 0.00 0.00 Array#size > 0.00 1.27 0.00 20 0.00 0.00 IO#close > 0.00 1.27 0.00 8 0.00 0.00 File#rename > 0.00 1.27 0.00 87 0.00 0.00 String#index > 0.00 1.27 0.00 17 0.00 0.00 FileFormat:: > WavFile#initialize > 0.00 1.27 0.00 1 0.00 90.00 FileFormat:: > FileConcat#concatFiles > 0.00 1.27 0.00 2 0.00 0.00 Kernel.open > 0.00 1.27 0.00 2 0.00 0.00 Integer#downto > 0.00 1.27 0.00 4 0.00 0.00 FileFormat:: > FileConcat#writeBytes > 0.00 1.27 0.00 1 0.00 30.00 FileFormat:: > FileConcat#concat_data_block > 0.00 1.27 0.00 476 0.00 0.00 NilClass#nil? > 0.00 1.27 0.00 20 0.00 0.00 File#initialize > 0.00 1.27 0.00 478 0.00 0.00 String#% > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > LogDevice#add_log_header > 0.00 1.27 0.00 18 0.00 2.78 FileFormat:: > WavFile#subChunk1Size > 0.00 1.27 0.00 2 0.00 0.00 Logger:: > LogDevice#shift_log_age > 0.00 1.27 0.00 318 0.00 0.00 IO#write > 0.00 1.27 0.00 238 0.00 0.00 String#<< > 0.00 1.27 0.00 238 0.00 0.00 Kernel.is_a? > 0.00 1.27 0.00 222 0.00 0.00 Fixnum#to_s > 0.00 1.27 0.00 34 0.00 0.00 File#size > 0.00 1.27 0.00 1 0.00 1270.00 #toplevel > > JRuby: > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 10.27 1.25 1.25 203 6.17 7.84 Integer#times > 9.64 2.43 1.17 238 4.94 36.55 Logger#add > 6.57 3.23 0.80 238 3.37 5.86 > > MonitorMixin.mon_exit > > 5.23 3.86 0.64 238 2.68 4.19 Logger:: > Formatter#format_datetime > 4.92 4.46 0.60 238 2.52 19.33 MonitorMixin. > mon_synchronize > 4.37 5.00 0.53 274 1.95 1.95 IO#write > 4.12 5.50 0.50 238 2.11 5.62 Logger:: > LogDevice#check_shift_log > 3.36 5.91 0.41 238 1.72 3.01 > > MonitorMixin.mon_enter > > 3.23 6.30 0.39 497 0.79 1.52 Class#new > 3.08 6.68 0.38 238 1.58 1.65 > > Logger::Formatter#msg2str > > 2.33 6.96 0.28 238 1.19 1.62 > > Logger#format_severity > > 2.33 7.24 0.28 238 1.19 37.75 Logger#info > 2.21 7.51 0.27 238 1.13 7.65 > > Logger::Formatter#call > > 2.18 7.78 0.27 238 1.12 1.12 > > File::Stat#initialize > > 2.08 8.03 0.25 17 14.94 658.12 FileFormat:: > WavFile#getInfo > 1.71 8.24 0.21 238 0.88 1.00 > > MonitorMixin.mon_acquire > > 1.70 8.45 0.21 87 2.38 4.87 FileFormat:: > WavFile#dataPos > 1.62 8.65 0.20 177 1.12 10.50 FileFormat:: > WavFile#readBigNum > 1.51 8.83 0.18 478 0.38 0.55 String#% > 1.44 9.01 0.18 238 0.74 8.39 > > Logger#format_message > > 1.40 9.18 0.17 476 0.36 0.36 NilClass#nil? > 1.37 9.35 0.17 238 0.70 1.08 > > MonitorMixin.mon_release > > 1.32 9.51 0.16 238 0.68 0.68 Time#strftime > 1.31 9.67 0.16 298 0.54 0.54 IO#pos= > 1.23 9.82 0.15 915 0.16 0.16 > > FileFormat::WavFile#file > > 1.19 9.96 0.15 238 0.61 19.94 > > Logger::LogDevice#write > > 1.10 10.10 0.13 952 0.14 0.14 > > ##critical= > > 1.00 10.22 0.12 238 0.51 0.80 MonitorMixin. > mon_check_owner > 0.91 10.33 0.11 530 0.21 0.21 IO#getc > 0.85 10.43 0.10 238 0.43 0.43 Kernel.is_a? > 0.85 10.54 0.10 1060 0.10 0.10 Fixnum#* > 0.83 10.64 0.10 239 0.42 0.42 Array#[] > 0.81 10.74 0.10 476 0.21 0.21 Fixnum#> > 0.75 10.83 0.09 476 0.19 0.19 Array#shift > 0.72 10.91 0.09 965 0.09 0.09 Fixnum#+ > 0.71 11.00 0.09 8 10.75 1494.63 Array#each > 0.71 11.09 0.09 34 2.53 2.53 IO#read > 0.66 11.17 0.08 238 0.34 2.50 File#stat > 0.66 11.25 0.08 238 0.34 0.34 Time#usec > 0.64 11.33 0.08 238 0.33 0.33 NilClass#to_s > 0.62 11.40 0.08 238 0.32 0.32 > > Kernel.respond_to? > > 0.61 11.47 0.07 35 2.11 11.74 FileFormat:: > WavFile#audioFormat > 0.57 11.54 0.07 344 0.20 0.21 Fixnum#== > 0.51 11.61 0.06 476 0.13 0.13 > > ##current > > 0.40 11.65 0.05 238 0.21 0.21 Fixnum#< > 0.33 11.69 0.04 325 0.12 0.12 Kernel.== > 0.32 11.73 0.04 17 2.29 5.71 > > FileFormat::WavFile#exist? > > 0.25 11.76 0.03 1 31.00 31.00 File#initialize > 0.25 11.79 0.03 222 0.14 0.14 Fixnum#to_s > 0.24 11.82 0.03 85 0.34 0.34 FileFormat:: > WavFile#fileDir > 0.21 11.85 0.02 238 0.11 0.11 > > Kernel.block_given? > > 0.20 11.87 0.02 240 0.10 0.10 Time#initialize > 0.19 11.90 0.02 17 1.35 1.71 FileFormat:: > WavFile#readBytes > 0.19 11.92 0.02 238 0.10 0.10 > > ##pass > > 0.17 11.94 0.02 17 1.24 16.71 FileFormat:: > WavFile#extraParamSize > 0.15 11.96 0.02 17 1.06 1.94 FileFormat:: > WavFile#openFile > 0.15 11.98 0.02 238 0.08 0.08 Module#=== > 0.14 11.99 0.02 355 0.05 0.05 Fixnum#- > 0.13 12.01 0.02 34 0.47 23.35 FileFormat:: > WavFile#subChunk2Size > 0.13 12.02 0.02 87 0.18 0.18 IO#readline > 0.10 12.04 0.01 18 0.67 16.67 FileFormat:: > WavFile#bitPerSample > 0.10 12.05 0.01 238 0.05 0.05 File::Stat#size > 0.09 12.06 0.01 238 0.05 0.05 Kernel.nil? > 0.08 12.07 0.01 1 10.00 801.00 FileFormat:: > FileConcat#concatFiles > 0.08 12.08 0.01 17 0.59 0.59 FileFormat:: > WavFile#initialize > 0.07 12.09 0.01 17 0.53 0.53 > > ##open > > 0.07 12.10 0.01 34 0.26 0.38 FileFormat:: > WavFile#fileSize > 0.07 12.11 0.01 18 0.44 5.67 FileFormat:: > WavFile#sampleRate > 0.07 12.11 0.01 87 0.09 0.09 String#index > 0.05 12.12 0.01 9 0.67 4.78 FileFormat:: > FileConcat#writeData > 0.05 12.12 0.01 17 0.35 0.35 FileTest.exist? > 0.04 12.13 0.01 2 2.50 8.00 Integer#downto > 0.04 12.14 0.01 18 0.28 6.17 FileFormat:: > WavFile#subChunk1Size > 0.04 12.14 0.01 18 0.28 4.67 FileFormat:: > WavFile#blockAlign > 0.04 12.15 0.00 17 0.29 0.71 FileFormat:: > WavFile#chunkSize > 0.04 12.15 0.00 18 0.28 12.22 FileFormat:: > WavFile#byteRate > 0.03 12.15 0.00 34 0.12 0.12 FileTest.size > 0.03 12.16 0.00 44 0.09 0.09 IO#putc > 0.03 12.16 0.00 18 0.22 0.22 IO#to_io > 0.02 12.17 0.00 17 0.18 5.82 FileFormat:: > WavFile#extraParams > 0.02 12.17 0.00 2 1.50 3.50 Logger:: > LogDevice#create_logfile > 0.02 12.17 0.00 20 0.15 0.15 IO#close > 0.02 12.17 0.00 17 0.12 0.12 Array#<< > 0.02 12.18 0.00 8 0.25 0.25 > > ##rename > > 0.02 12.18 0.00 28 0.07 0.07 Fixnum#<< > 0.02 12.18 0.00 56 0.04 0.04 Fixnum#>> > 0.02 12.18 0.00 18 0.11 8.94 FileFormat:: > WavFile#numChannels > 0.02 12.18 0.00 51 0.04 0.04 IO#eof > 0.01 12.18 0.00 2 0.50 2.00 Logger:: > LogDevice#add_log_header > 0.01 12.18 0.00 2 0.50 0.50 Time#to_s > 0.00 12.18 0.00 2 0.00 0.00 IO#sync= > 0.00 12.18 0.00 2 0.00 12.50 Logger:: > LogDevice#shift_log_age > 0.00 12.18 0.00 6 0.00 0.00 > > ##exist? > > 0.00 12.18 0.00 1 0.00 0.00 Array#length > 0.00 12.18 0.00 2 0.00 0.00 Kernel.open > 0.00 12.18 0.00 1 0.00 31.00 FileFormat:: > FileConcat#initialize > 0.00 12.18 0.00 17 0.00 0.00 Array#to_s > 0.00 12.18 0.00 1 0.00 209.00 FileFormat:: > FileConcat#concat_data_block > 0.00 12.18 0.00 4 0.00 0.00 Fixnum#| > 0.00 12.18 0.00 4 0.00 1.00 FileFormat:: > FileConcat#writeBytes > 0.00 12.19 0.00 1 0.00 12187.00 #toplevel > > This performance of JRuby is rather bad. Reasons may come from: > 1. JRuby is in nature very slow. We can not do anything to this 2. > JRuby's startup time is longer than that of Ruby. I wonder this > situation would be improved if we have had on in-memory JVM > > > Peter K Chan wrote: > Not anymore, Nate. :) > > JRuby WAS slow six months ago, but it has come a long way. Check this > > out: > > > > http://headius.blogspot.com/2007/04/paving-road-to-jruby-10-performance. > html > > Summary: In interpretive mode, JRuby is no more than 2x slower, and > that's including JVM startup and lack of hotspot warm up. In > unoptimized compiled mode, JRuby often beats C Ruby. I have been using > JRuby in my project, and I haven't had any performance complaints > since 2 months ago. > > Peter > ________________________________________ > From: chicagogroup-members-list-bounces at rubyforge.org [mailto: > chicagogroup-members-list-bounces at rubyforge.org ] On Behalf Of Nate > > Kirby > > Sent: Tuesday, May 29, 2007 2:23 AM > To: Chirb discussion list > Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t > > Peter, > > JRuby is slow. Try RJB (http://rjb.rubyforge.org/) > > Nate > > Peter K Chan wrote: > Sure! I will be up for some Uger-hacking/feedback-taking (I also need > > to > > apply Colin's patch from a while ago and push it out). > > Hmm...maybe I should think of a lightning talk on JRuby or something. > > Peter > > -----Original Message----- > From: chicagogroup-members-list-bounces at rubyforge.org > [mailto:chicagogroup-members-list-bounces at rubyforge.org ] On Behalf Of > Evan Farrar > Sent: Monday, May 28, 2007 5:51 PM > To: Chirb discussion list > Subject: Re: [Chirb] time to rsvp for the mystery meeting! W00t > > Woohoo Lightning talks! I will definitely come with something. I also > would like to call together a uger hacksession if Peter Chang is > around for the meeting. > > On 5/28/07, Josh Cronemeyer wrote: > > Ok, nobody signed up for the talk and we are a week away from the next > CHIRB. Soooo, unless anyone objects I think we should have another > "lightning talk / code pit" session like the one last december. If > > you can > > prepare something that you can get through in 10 minutes or so, please > > do. > > Alternatively you can put out a request for a talk on a certain topic > > and > > perhaps that will inspire somebody. I'm mulling over a topic just to > > force > > myself to learn something new (Why's camping framework). But I make > > no > > promises :) Let's have fun with this and take advantage of the chance > > for > > all of us to talk. No pressure!!!! > > http://chirb.org/event/show/18 > > Josh Cronemeyer > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > _______________________________________________ ChicagoGroup-Members-List at rubyforge.org http://rubyforge.org/mailman/listinfo/chicagogroup-members-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/30a02f00/attachment-0001.html From danw at wellsoftware.com Mon Jun 18 15:30:36 2007 From: danw at wellsoftware.com (Dan Wellisch) Date: Mon, 18 Jun 2007 14:30:36 -0500 Subject: [Chirb] Agile Development group Message-ID: <4676DD5C.2070706@wellsoftware.com> All: Given the fact that I live/work in the Northwest Suburbs, I am wondering if there are other people in the Northshore, North, and Northwest Suburbs (e.g. Northbrook, Glenview, Buffalo Grove, Lake Zurich, etc......) that would be interested in forming a group for focusing on Agile Development/XP/TDD. I envision not only developers but first level managers as being part of the group. I am more interested in focussing the group on what the best tools are for the job than any particular technology, although I think presentations of particular technologies would be a good part of the group. The focus would be applied Agile Development. Secondary, would be the tools used. In this way, we could combine first level managers in the group and have them really contribute. I want to get some feedback from those that live in the Northern areas. Commute time to the meetings should be 30 minutes or less. Meetings could be as often as bi-monthly. The point would be to establish a core group, yet always be open to inviting new people. As you all know Agile development is the new buzzword. It is actually an evolution of RAD and quick prototyping. Thoughts?? Thanks, Dan -- Dan Wellisch Wellisch Software Technologies, Inc. www.wellsoftware.com 847-254-Well (9355) From peter.fitzgibbons at gmail.com Mon Jun 18 15:46:07 2007 From: peter.fitzgibbons at gmail.com (Peter Fitzgibbons) Date: Mon, 18 Jun 2007 14:46:07 -0500 Subject: [Chirb] Agile Development group In-Reply-To: <4676DD5C.2070706@wellsoftware.com> References: <4676DD5C.2070706@wellsoftware.com> Message-ID: <670a00380706181246n5e084461h523e0d2d2e467423@mail.gmail.com> HI Dan, I'm interested. I live in Evanston now. I look forward to seeing further info and replies on this. Thanks for posting the invite! Peter Fitzgibbons On 6/18/07, Dan Wellisch wrote: > > All: > > Given the fact that I live/work in the Northwest Suburbs, I am wondering > if there are other people in the Northshore, North, and Northwest Suburbs > (e.g. Northbrook, Glenview, Buffalo Grove, Lake Zurich, etc......) that > would be interested in forming a group for focusing on Agile > Development/XP/TDD. > > I envision not only developers but first level managers as being part of > the group. I am more interested in focussing the group on what the best > tools are for > the job than any particular technology, although I think presentations > of particular technologies would be a good part of the group. > > The focus would be applied Agile Development. Secondary, would be the > tools used. In this way, we could combine first level managers in the > group > and have them really contribute. > > I want to get some feedback from those that live in the Northern areas. > Commute time to the meetings should be 30 minutes or less. Meetings > could be as often as bi-monthly. The point would be to establish a core > group, yet always be open to inviting new people. > > As you all know Agile development is the new buzzword. It is actually > an evolution of RAD and quick prototyping. > > Thoughts?? > > Thanks, > > Dan > > -- > Dan Wellisch > Wellisch Software Technologies, Inc. > www.wellsoftware.com > 847-254-Well (9355) > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > -- ------------------------------ Y2Cicadas - Chicago's worst weather report in 17 years ? ------------------------------ Peter Fitzgibbons -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/95350442/attachment.html From natebkirby at yahoo.com Mon Jun 18 16:13:19 2007 From: natebkirby at yahoo.com (Nate Kirby) Date: Tue, 19 Jun 2007 05:13:19 +0900 Subject: [Chirb] Agile Development group In-Reply-To: <670a00380706181246n5e084461h523e0d2d2e467423@mail.gmail.com> References: <4676DD5C.2070706@wellsoftware.com> <670a00380706181246n5e084461h523e0d2d2e467423@mail.gmail.com> Message-ID: <4676E75F.3060204@yahoo.com> You should all be aware of ChaD (Chicago Area Agile Developers - http://wiki.cs.uiuc.edu/CHAD/What+is+ChAD ). They were quite active in the early 2000's (2000-2005) but seemed to have declined. There has been some activity on the mailing list about getting together, but as near as I can tell not much has happened. If you want a critical mass I would post to Chad also. Blessings, Nate Peter Fitzgibbons wrote: > HI Dan, > I'm interested. I live in Evanston now. > > I look forward to seeing further info and replies on this. > > Thanks for posting the invite! > > Peter Fitzgibbons > > On 6/18/07, *Dan Wellisch* > wrote: > > All: > > Given the fact that I live/work in the Northwest Suburbs, I am > wondering > if there are other people in the Northshore, North, and Northwest > Suburbs > (e.g. Northbrook, Glenview, Buffalo Grove, Lake Zurich, etc......) > that > would be interested in forming a group for focusing on Agile > Development/XP/TDD. > > I envision not only developers but first level managers as being > part of > the group. I am more interested in focussing the group on what > the best > tools are for > the job than any particular technology, although I think presentations > of particular technologies would be a good part of the group. > > The focus would be applied Agile Development. Secondary, would be > the > tools used. In this way, we could combine first level managers in > the group > and have them really contribute. > > I want to get some feedback from those that live in the Northern > areas. > Commute time to the meetings should be 30 minutes or less. Meetings > could be as often as bi-monthly. The point would be to establish > a core > group, yet always be open to inviting new people. > > As you all know Agile development is the new buzzword. It is actually > an evolution of RAD and quick prototyping. > > Thoughts?? > > Thanks, > > Dan > > -- > Dan Wellisch > Wellisch Software Technologies, Inc. > www.wellsoftware.com > 847-254-Well (9355) > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > > > -- > ------------------------------ > Y2Cicadas - Chicago's worst weather report in 17 years ? > ------------------------------ > Peter Fitzgibbons > ------------------------------------------------------------------------ > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.472 / Virus Database: 269.9.0/852 - Release Date: 6/17/2007 8:23 AM > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070619/b97c3728/attachment.html From jcroneme at thoughtworks.com Mon Jun 18 16:53:25 2007 From: jcroneme at thoughtworks.com (Josh Cronemeyer) Date: Mon, 18 Jun 2007 15:53:25 -0500 Subject: [Chirb] Agile Development group In-Reply-To: <4676DD5C.2070706@wellsoftware.com> Message-ID: > As you all know Agile development is the new buzzword. It is actually > an evolution of RAD and quick prototyping. I didn't know what RAD was so I looked it up. RAD could very well be an ancestor of Agile processes. The iterative requirement gathering and development are critical to Agile. However RAD's emphasis on tools, UML, and code generators seems to go against Agile principles. Just to clarify. (Capital A) Agile is a classification and set of principals that describe various lightweight development methods (think SCRUM and XP), not a methodology itself. Many of the methods that can be classified as Agile predate the term Agile by years. Here is a link to a very good description of Agile and how it relates to XP at object mentor's site. http://www.objectmentor.com/omSolutions/agile_xp_differences.html I think it really helps put Agile into perspective, at least from the perspective of the people who initially concieved of Agile. Now that we have the (lowercase a) agile buzzword in circulation it is sometimes difficult to understand what people are talking about. The group sounds like an interesting idea. I don't know of anything like it in the chicago area. Josh Cronemeyer chicagogroup-members-list-bounces at rubyforge.org wrote on 06/18/2007 02:30:36 PM: > All: > > Given the fact that I live/work in the Northwest Suburbs, I am wondering > if there are other people in the Northshore, North, and Northwest Suburbs > (e.g. Northbrook, Glenview, Buffalo Grove, Lake Zurich, etc......) that > would be interested in forming a group for focusing on Agile > Development/XP/TDD. > > I envision not only developers but first level managers as being part of > the group. I am more interested in focussing the group on what the best > tools are for > the job than any particular technology, although I think presentations > of particular technologies would be a good part of the group. > > The focus would be applied Agile Development. Secondary, would be the > tools used. In this way, we could combine first level managers in the group > and have them really contribute. > > I want to get some feedback from those that live in the Northern areas. > Commute time to the meetings should be 30 minutes or less. Meetings > could be as often as bi-monthly. The point would be to establish a core > group, yet always be open to inviting new people. > > As you all know Agile development is the new buzzword. It is actually > an evolution of RAD and quick prototyping. > > Thoughts?? > > Thanks, > > Dan > > -- > Dan Wellisch > Wellisch Software Technologies, Inc. > www.wellsoftware.com > 847-254-Well (9355) > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/bebb5b9b/attachment.html From cstejerean at gmail.com Mon Jun 18 19:28:59 2007 From: cstejerean at gmail.com (Cosmin Stejerean) Date: Mon, 18 Jun 2007 18:28:59 -0500 Subject: [Chirb] Agile Development group In-Reply-To: <4676DD5C.2070706@wellsoftware.com> References: <4676DD5C.2070706@wellsoftware.com> Message-ID: <383bbcce0706181628s4f900f41u77ac33f9fac9f7c1@mail.gmail.com> I'm interested in this. I currently live in Lake Bluff and often have a hard time convincing myself to commute all the way downtown for a meeting. I would appreciate a meeting in the north suburbs. - Cosmin On 6/18/07, Dan Wellisch wrote: > > All: > > Given the fact that I live/work in the Northwest Suburbs, I am wondering > if there are other people in the Northshore, North, and Northwest Suburbs > (e.g. Northbrook, Glenview, Buffalo Grove, Lake Zurich, etc......) that > would be interested in forming a group for focusing on Agile > Development/XP/TDD. > > I envision not only developers but first level managers as being part of > the group. I am more interested in focussing the group on what the best > tools are for > the job than any particular technology, although I think presentations > of particular technologies would be a good part of the group. > > The focus would be applied Agile Development. Secondary, would be the > tools used. In this way, we could combine first level managers in the > group > and have them really contribute. > > I want to get some feedback from those that live in the Northern areas. > Commute time to the meetings should be 30 minutes or less. Meetings > could be as often as bi-monthly. The point would be to establish a core > group, yet always be open to inviting new people. > > As you all know Agile development is the new buzzword. It is actually > an evolution of RAD and quick prototyping. > > Thoughts?? > > Thanks, > > Dan > > -- > Dan Wellisch > Wellisch Software Technologies, Inc. > www.wellsoftware.com > 847-254-Well (9355) > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/c8de5a20/attachment-0001.html From sergio_pereira at msn.com Tue Jun 19 00:04:57 2007 From: sergio_pereira at msn.com (Sergio Pereira) Date: Mon, 18 Jun 2007 23:04:57 -0500 Subject: [Chirb] Agile Development group Message-ID: I like the idea too. I'm not exactly an agilist but I'd be very interested in learning more and getting in touch with people doing Agile.I live in Grayslake but any meeting North of Lake-Cook Rd is more than convenient for me. - Sergio> Date: Mon, 18 Jun 2007 14:30:36 -0500> From: Dan Wellisch > Subject: [Chirb] Agile Development group> To: chicagogroup-members-list at rubyforge.org> Message-ID: <4676DD5C.2070706 at wellsoftware.com>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > All:> > Given the fact that I live/work in the Northwest Suburbs, I am wondering > if there are other people in the Northshore, North, and Northwest Suburbs> (e.g. Northbrook, Glenview, Buffalo Grove, Lake Zurich, etc......) that > would be interested in forming a group for focusing on Agile > Development/XP/TDD.> > I envision not only developers but first level managers as being part of > the group. I am more interested in focussing the group on what the best > tools are for> the job than any particular technology, although I think presentations > of particular technologies would be a good part of the group. > > The focus would be applied Agile Development. Secondary, would be the > tools used. In this way, we could combine first level managers in the group> and have them really contribute.> > I want to get some feedback from those that live in the Northern areas. > Commute time to the meetings should be 30 minutes or less. Meetings> could be as often as bi-monthly. The point would be to establish a core > group, yet always be open to inviting new people.> > As you all know Agile development is the new buzzword. It is actually > an evolution of RAD and quick prototyping. > > Thoughts??> > Thanks,> > Dan> > -- > Dan Wellisch> Wellisch Software Technologies, Inc.> www.wellsoftware.com> 847-254-Well (9355) _________________________________________________________________ With Windows Live Hotmail, you can personalize your inbox with your favorite color. www.windowslive-hotmail.com/learnmore/personalize.html?locale=en-us&ocid=TXT_TAGLM_HMWL_reten_addcolor_0607 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070618/d5e401f6/attachment.html From micah at 8thlight.com Tue Jun 19 10:07:17 2007 From: micah at 8thlight.com (Micah Martin) Date: Tue, 19 Jun 2007 09:07:17 -0500 Subject: [Chirb] Agile Development group In-Reply-To: <4676DD5C.2070706@wellsoftware.com> References: <4676DD5C.2070706@wellsoftware.com> Message-ID: <5B003CB2-7B76-446A-961B-C76A41EE1C8F@8thlight.com> I'd be open for a Northwest meeting. Coming from Round Lake, it'd be a huge break not to travel all the way down town. Micah On Jun 18, 2007, at 2:30 PM, Dan Wellisch wrote: > All: > > Given the fact that I live/work in the Northwest Suburbs, I am > wondering > if there are other people in the Northshore, North, and Northwest > Suburbs > (e.g. Northbrook, Glenview, Buffalo Grove, Lake Zurich, etc......) > that > would be interested in forming a group for focusing on Agile > Development/XP/TDD. > > I envision not only developers but first level managers as being > part of > the group. I am more interested in focussing the group on what the > best > tools are for > the job than any particular technology, although I think presentations > of particular technologies would be a good part of the group. > > The focus would be applied Agile Development. Secondary, would be the > tools used. In this way, we could combine first level managers in > the group > and have them really contribute. > > I want to get some feedback from those that live in the Northern > areas. > Commute time to the meetings should be 30 minutes or less. Meetings > could be as often as bi-monthly. The point would be to establish a > core > group, yet always be open to inviting new people. > > As you all know Agile development is the new buzzword. It is actually > an evolution of RAD and quick prototyping. > > Thoughts?? > > Thanks, > > Dan > > -- > Dan Wellisch > Wellisch Software Technologies, Inc. > www.wellsoftware.com > 847-254-Well (9355) > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list From danw at wellsoftware.com Wed Jun 20 16:06:13 2007 From: danw at wellsoftware.com (Dan Wellisch) Date: Wed, 20 Jun 2007 15:06:13 -0500 Subject: [Chirb] Need Expert Rails Developer As A Partner Message-ID: <467988B5.4080804@wellsoftware.com> Hello: In my search for new work, I have come across a contact out of Berkley, CA. This contact designs GUIs and Project Manages for his own firm. Given that I am new to Rails (yet a seasoned developer using Java on server and client side, and with 19 years software experience), I have convinced my contact that a team of myself (Rails newbie) plus an expert Rails developer would be able to procure a series of projects from this firm. The idea would be to start small and see where it goes. For me, it would be a great opportunity to work with an expert. I would be open to working together either face-to-face or perhaps better in a virtual environment using VNC or something similar (using XP, TDD, and other Agile practices that make sense). Do any of you Rails experts have any extra time to do a project? The commitment would start at roughly 16 hours/week. The idea would be to build up over time into something larger. Let me know of your interest. Thanks, Dan -- Dan Wellisch Wellisch Software Technologies, Inc. www.wellsoftware.com 847-254-Well (9355) From jcroneme at thoughtworks.com Wed Jun 27 16:48:29 2007 From: jcroneme at thoughtworks.com (Josh Cronemeyer) Date: Wed, 27 Jun 2007 15:48:29 -0500 Subject: [Chirb] July Meeting! Message-ID: The summer is flying by! Another month has come and gone. So the big (and rather late) question is, "Does anyone have anything planned for the July meeting?" I can volunteer to do a quick demo/talk on CC.rb, but it won't take up more than 15-20 minutes. Josh Cronemeyer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070627/96d87e3b/attachment.html From brendan at usergenic.com Wed Jun 27 19:29:30 2007 From: brendan at usergenic.com (Brendan Baldwin) Date: Wed, 27 Jun 2007 18:29:30 -0500 Subject: [Chirb] July Meeting! In-Reply-To: References: Message-ID: <7e757dc00706271629q319a6aaep3b55bb518288ecbc@mail.gmail.com> Josh-- I created a builder plugin for CC.rb to do campfire notifications with blame/praise; feel free to incorporate in your demo // I could work with you to do that if you have any questions. :-D http://usergenic.com/svn/public/ruby/cruisecontrol/builder_plugins/campfire_notifier/trunk/ If anyone is interested I'd like to put in my vote for leading/participating in a discussion about REST architecture concerns and practices in Rails apps, including some code examples. I think we should definitely get into some more actual code demo/walk-thrus this time; I realize my hurried presentation last time didn't actually do that to explain what was going on under the covers and its been bugging me since :-P --Brendan On 6/27/07, Josh Cronemeyer wrote: > > > The summer is flying by! Another month has come and gone. So the big > (and rather late) question is, "Does anyone have anything planned for the > July meeting?" > > I can volunteer to do a quick demo/talk on CC.rb, but it won't take up > more than 15-20 minutes. > > Josh Cronemeyer > _______________________________________________ > ChicagoGroup-Members-List > @rubyforge.org > http://rubyforge.org/mailman > /listinfo/chicagogroup-members-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070627/e81a0dfc/attachment.html From peter at oaktop.com Wed Jun 27 19:55:20 2007 From: peter at oaktop.com (Peter K Chan) Date: Wed, 27 Jun 2007 19:55:20 -0400 Subject: [Chirb] July Meeting! In-Reply-To: References: Message-ID: I want to do a presentation on my project to Chirb, but I won't be ready until August (or September, depending on my traveling arrangement conflict). If someone have a full presentation in mind, please speak up. Otherwise, we can also organize the meeting as a series of small talks. Personally, I can do micro-talks on JRuby or another little framework that I developed for my app (these are small talks though; I don't plan on preparing for them, and it will show). Peter From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Josh Cronemeyer Sent: Wednesday, June 27, 2007 3:48 PM To: Chirb discussion list Subject: [Chirb] July Meeting! The summer is flying by! Another month has come and gone. So the big (and rather late) question is, "Does anyone have anything planned for the July meeting?" I can volunteer to do a quick demo/talk on CC.rb, but it won't take up more than 15-20 minutes. Josh Cronemeyer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070627/bd52544c/attachment-0001.html From jcroneme at thoughtworks.com Wed Jun 27 20:01:09 2007 From: jcroneme at thoughtworks.com (Josh Cronemeyer) Date: Wed, 27 Jun 2007 19:01:09 -0500 Subject: [Chirb] July Meeting! In-Reply-To: Message-ID: Now that I think about it, I'm pretty sure that if somebody had a big presentation brewing they wouldn't wait until the week before to spring it on us. Let's plan for micro talks, which means we'll take you up on that peter :) Josh Cronemeyer chicagogroup-members-list-bounces at rubyforge.org wrote on 06/27/2007 06:55:20 PM: > I want to do a presentation on my project to Chirb, but I won?t be > ready until August (or September, depending on my traveling > arrangement conflict). > > If someone have a full presentation in mind, please speak up. > Otherwise, we can also organize the meeting as a series of small > talks. Personally, I can do micro-talks on JRuby or another little > framework that I developed for my app (these are small talks though; I > don?t plan on preparing for them, and it will show). > > Peter > > From: chicagogroup-members-list-bounces at rubyforge.org [mailto: > chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Josh Cronemeyer > Sent: Wednesday, June 27, 2007 3:48 PM > To: Chirb discussion list > Subject: [Chirb] July Meeting! > > > The summer is flying by! Another month has come and gone. So the big > (and rather late) question is, "Does anyone have anything planned for > the July meeting?" > > I can volunteer to do a quick demo/talk on CC.rb, but it won't take up > more than 15-20 minutes. > > Josh Cronemeyer_______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070627/6694d4c9/attachment.html From jcroneme at thoughtworks.com Wed Jun 27 20:03:35 2007 From: jcroneme at thoughtworks.com (Josh Cronemeyer) Date: Wed, 27 Jun 2007 19:03:35 -0500 Subject: [Chirb] July Meeting! In-Reply-To: <7e757dc00706271629q319a6aaep3b55bb518288ecbc@mail.gmail.com> Message-ID: Brendan, Sounds good. I don't think we will have time to get together before the meeting on this, but you might jump in any time during my talk and show off your plugin. Josh Cronemeyer chicagogroup-members-list-bounces at rubyforge.org wrote on 06/27/2007 06:29:30 PM: > Josh-- > > I created a builder plugin for CC.rb to do campfire notifications with > blame/praise; feel free to incorporate in your demo // I could work > with you to do that if you have any questions. :-D > > http://usergenic. > com/svn/public/ruby/cruisecontrol/builder_plugins/campfire_notifier/trunk/ > > If anyone is interested I'd like to put in my vote for > leading/participating in a discussion about REST architecture concerns > and practices in Rails apps, including some code examples. > > > I think we should definitely get into some more actual code demo/walk- > thrus this time; I realize my hurried presentation last time didn't > actually do that to explain what was going on under the covers and its > been bugging me since :-P > > --Brendan > > On 6/27/07, Josh Cronemeyer < jcroneme at thoughtworks.com> wrote: > > The summer is flying by! Another month has come and gone. So the big > (and rather late) question is, "Does anyone have anything planned for > the July meeting?" > > I can volunteer to do a quick demo/talk on CC.rb, but it won't take up > more than 15-20 minutes. > > Josh Cronemeyer > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070627/2c237005/attachment.html From jcroneme at thoughtworks.com Wed Jun 27 20:07:07 2007 From: jcroneme at thoughtworks.com (Josh Cronemeyer) Date: Wed, 27 Jun 2007 19:07:07 -0500 Subject: [Chirb] July Meeting! In-Reply-To: Message-ID: The RSVP page is up for July! http://www.chirb.org/event/show/19 Be there or be square! Josh Cronemeyer chicagogroup-members-list-bounces at rubyforge.org wrote on 06/27/2007 07:03:35 PM: > > Brendan, > > Sounds good. I don't think we will have time to get together before > the meeting on this, but you might jump in any time during my talk and > show off your plugin. > > Josh Cronemeyer > > chicagogroup-members-list-bounces at rubyforge.org wrote on 06/27/2007 06:29:30 PM: > > > Josh-- > > > > I created a builder plugin for CC.rb to do campfire notifications with > > blame/praise; feel free to incorporate in your demo // I could work > > with you to do that if you have any questions. :-D > > > > http://usergenic. > > com/svn/public/ruby/cruisecontrol/builder_plugins/campfire_notifier/trunk/ > > > > If anyone is interested I'd like to put in my vote for > > leading/participating in a discussion about REST architecture concerns > > and practices in Rails apps, including some code examples. > > > > > > I think we should definitely get into some more actual code demo/walk- > > thrus this time; I realize my hurried presentation last time didn't > > actually do that to explain what was going on under the covers and its > > been bugging me since :-P > > > > --Brendan > > > > On 6/27/07, Josh Cronemeyer < jcroneme at thoughtworks.com> wrote: > > > > The summer is flying by! Another month has come and gone. So the big > > (and rather late) question is, "Does anyone have anything planned for > > the July meeting?" > > > > I can volunteer to do a quick demo/talk on CC.rb, but it won't take up > > more than 15-20 minutes. > > > > Josh Cronemeyer > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > > > > _______________________________________________ > > ChicagoGroup-Members-List at rubyforge.org > > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list > _______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070627/85142724/attachment.html From peter at oaktop.com Wed Jun 27 21:57:38 2007 From: peter at oaktop.com (Peter K Chan) Date: Wed, 27 Jun 2007 21:57:38 -0400 Subject: [Chirb] July Meeting! In-Reply-To: References: Message-ID: Sounds good. My talks will be informal and short, so we should have plenty of time for anyone else who may want to talk. Peter From: chicagogroup-members-list-bounces at rubyforge.org [mailto:chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Josh Cronemeyer Sent: Wednesday, June 27, 2007 7:01 PM To: Chirb discussion list Cc: Chirb discussion list; chicagogroup-members-list-bounces at rubyforge.org Subject: Re: [Chirb] July Meeting! Now that I think about it, I'm pretty sure that if somebody had a big presentation brewing they wouldn't wait until the week before to spring it on us. Let's plan for micro talks, which means we'll take you up on that peter :) Josh Cronemeyer chicagogroup-members-list-bounces at rubyforge.org wrote on 06/27/2007 06:55:20 PM: > I want to do a presentation on my project to Chirb, but I won't be > ready until August (or September, depending on my traveling > arrangement conflict). > > If someone have a full presentation in mind, please speak up. > Otherwise, we can also organize the meeting as a series of small > talks. Personally, I can do micro-talks on JRuby or another little > framework that I developed for my app (these are small talks though; I > don't plan on preparing for them, and it will show). > > Peter > > From: chicagogroup-members-list-bounces at rubyforge.org [mailto: > chicagogroup-members-list-bounces at rubyforge.org] On Behalf Of Josh Cronemeyer > Sent: Wednesday, June 27, 2007 3:48 PM > To: Chirb discussion list > Subject: [Chirb] July Meeting! > > > The summer is flying by! Another month has come and gone. So the big > (and rather late) question is, "Does anyone have anything planned for > the July meeting?" > > I can volunteer to do a quick demo/talk on CC.rb, but it won't take up > more than 15-20 minutes. > > Josh Cronemeyer_______________________________________________ > ChicagoGroup-Members-List at rubyforge.org > http://rubyforge.org/mailman/listinfo/chicagogroup-members-list -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/chicagogroup-members-list/attachments/20070627/52898be9/attachment-0001.html From JAW at Techsocial.com Sat Jun 30 23:29:05 2007 From: JAW at Techsocial.com (Jonathan Andrew Wolter) Date: Sat, 30 Jun 2007 23:29:05 -0400 Subject: [Chirb] anybody going to erubycon.com enterprise ruby/rails conference in columbus? $250 / 3days Message-ID: <32ca7bf50706302029o369f1dd7r946ae40e5c943854@mail.gmail.com> Anybody interested in going to http://erubycon.com/ ? (Enterprise Ruby conf. in Columbus OH. July 16-18, mon-weds). Neal Ford, Bruce Tate, and others will be speaking. It remindes me of the No Fluff Just Stuff conferences - small audiences, interesting speakers, and affordable. It's under $250 for 3 days with a great bunch of speakers. Share a hotel room for about $40/night. You could take megabus.com/us/ for less than $55 round trip. I'll be out of town for a bit and will be driving in from ft wayne, otherwise I'd carpool. Please reply off-list if interested, -jonathan -- Connect http://linkedin.com/in/jawolter sms/cell: 765-532-6876 JAWspeak.com Techsocial.com "To know, and not to do, is not yet to know."