Hey all,
I''m looking for ways to optimize rspec and came upon something
interesting. If I remove handling for auto-generated descriptions (the
thing that allows you to say "specify { 5.should == 5 }" with no
description string) we get an average 35% performance increase per
expectation. 35%. That''s huge.
So - how bad do you think this would suck to remove that feature? Are
you using it yourself?
All thoughts welcome.
Thanks,
David
On Fri, Jul 4, 2008 at 1:45 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> Hey all, > > I''m looking for ways to optimize rspec and came upon something interesting. > If I remove handling for auto-generated descriptions (the thing that allows > you to say "specify { 5.should == 5 }" with no description string) we get an > average 35% performance increase per expectation. 35%. That''s huge. > > So - how bad do you think this would suck to remove that feature? Are you > using it yourself? > > All thoughts welcome.To be clear, this is for taking a spec like: it { 2.should == 2 } and then when running with the specdoc formatter, getting - should == 2 I personally don''t use specdoc format very often anyway. My intuition is that writing specs without a description (which I frequently use) is optimized for programmer clarity, so auto-generating a description for it is less important. I understand that the description would be used in a number of other places, including error messages, but in the case of error messages I just use line numbers. Basically, auto-generating descriptions are valuable, but fall way short of withholding a 35% performance improvement. Pat
On Jul 4, 2008, at 4:45 PM, David Chelimsky wrote:> > So - how bad do you think this would suck to remove that feature? > Are you using it yourself? > > All thoughts welcome.Wasn''t even aware that feature existed!
On Fri, Jul 4, 2008 at 4:45 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> So - how bad do you think this would suck to remove that feature? Are you > using it yourself?Personally, I *love* this feature, and would not like to see it go. One of my heuristics for a good spec is that it either a) has a clear spec doc string; or b) auto-formats to a clearly understandable doc string. I run spec -fs periodically to verify this. The fact that I can I can write a sizable subset of my specs in a very DRY way thanks to the auto-formatting feature is one of my favorite little perks of using RSpec. -- Avdi Home: http://avdi.org Developer Blog: http://avdi.org/devblog/ Twitter: http://twitter.com/avdi Journal: http://avdi.livejournal.com
On Fri, Jul 4, 2008 at 4:45 PM, David Chelimsky <dchelimsky at gmail.com> wrote:> > So - how bad do you think this would suck to remove that feature? Are you > using it yourself?I''m not, but would it be impractical to extract it out into some sort of module or helper and tell people to include it in their config.* block if they want to use it? -- Have Fun, Steve Eley
David Chelimsky wrote:> Hey all, > > I''m looking for ways to optimize rspec and came upon something > interesting. If I remove handling for auto-generated descriptions (the > thing that allows you to say "specify { 5.should == 5 }" with no > description string) we get an average 35% performance increase per > expectation. 35%. That''s huge. > > So - how bad do you think this would suck to remove that feature? Are > you using it yourself? > > All thoughts welcome. > > Thanks, > David > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-usersDavid, I personally like that feature, but I honestly don''t find myself using it too much. 35% is a lot. One suggestion would be to keep the functionality but move it to a different keyword so that the common "it"/"specify" case is made faster. That way we could have our cake and eat it too. I''m not too sure on what keyword could be used though. "Expect" comes to mind but I think that is because of Jay Fields expectations framework. Which, BTW, if we added support for that to coexist within rspec example groups then the need for rspec to support the feature natively would diminish. So that is another option that may be worth investigating. Could you maybe post the diff of your changes to turn off that feature? I''d be interested in seeing how much speed improvements I get with my slower spec suites. Thanks, Ben
On Sat, Jul 5, 2008 at 12:18 PM, Steve Eley <steve at deepsalt.com> wrote:> On Fri, Jul 4, 2008 at 4:45 PM, David Chelimsky <dchelimsky at gmail.com> wrote: >> So - how bad do you think this would suck to remove that feature? Are you >> using it yourself? > I''m not, but would it be impractical to extract it out into some sort > of module or helper and tell people to include it in their config.* > block if they want to use it?+1 config.enable_auto_generating_descriptions = true 35% is 35%... Mikel -- http://lindsaar.net/ Rails, RSpec, Puppet and Life blog....
On Jul 4, 2008, at 10:54 PM, Mikel Lindsaar wrote:> On Sat, Jul 5, 2008 at 12:18 PM, Steve Eley <steve at deepsalt.com> > wrote: >> On Fri, Jul 4, 2008 at 4:45 PM, David Chelimsky >> <dchelimsky at gmail.com> wrote: >>> So - how bad do you think this would suck to remove that feature? >>> Are you >>> using it yourself? >> I''m not, but would it be impractical to extract it out into some sort >> of module or helper and tell people to include it in their config.* >> block if they want to use it? > > +1 > > config.enable_auto_generating_descriptions = true > > 35% is 35%... > > Mikel >I would think autoloading rspec (with Module#autoload) would be a big speed up for features that aren''t used... Besides - where are the benchmarks? Scott
+1. This is a smart. On Fri, Jul 4, 2008 at 9:18 PM, Steve Eley <steve at deepsalt.com> wrote:> On Fri, Jul 4, 2008 at 4:45 PM, David Chelimsky <dchelimsky at gmail.com> wrote: >> >> So - how bad do you think this would suck to remove that feature? Are you >> using it yourself? > > I''m not, but would it be impractical to extract it out into some sort > of module or helper and tell people to include it in their config.* > block if they want to use it? > > > -- > Have Fun, > Steve Eley > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Fri, Jul 4, 2008 at 10:18 PM, Steve Eley <steve at deepsalt.com> wrote:> On Fri, Jul 4, 2008 at 4:45 PM, David Chelimsky <dchelimsky at gmail.com> > wrote: > > > > So - how bad do you think this would suck to remove that feature? Are you > > using it yourself? > > I''m not, but would it be impractical to extract it out into some sort > of module or helper and tell people to include it in their config.* > block if they want to use it? >+1 -- Zach Dennis http://www.continuousthinking.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080707/9781518d/attachment.html>
On Jul 04, 2008, at 9:45 pm, David Chelimsky wrote:> I''m looking for ways to optimize rspec and came upon something > interesting. If I remove handling for auto-generated descriptions > (the thing that allows you to say "specify { 5.should == 5 }" with > no description string) we get an average 35% performance increase > per expectation. 35%. That''s huge. > > So - how bad do you think this would suck to remove that feature? > Are you using it yourself?I was aware of it but never felt the need to use it Ashley -- http://www.patchspace.co.uk/ http://aviewfromafar.net/
On Jul 7, 2008, at 1:47 PM, Ashley Moran wrote:> > On Jul 04, 2008, at 9:45 pm, David Chelimsky wrote: > >> I''m looking for ways to optimize rspec and came upon something >> interesting. If I remove handling for auto-generated descriptions >> (the thing that allows you to say "specify { 5.should == 5 }" with >> no description string) we get an average 35% performance increase >> per expectation. 35%. That''s huge. >> >> So - how bad do you think this would suck to remove that feature? >> Are you using it yourself? > > I was aware of it but never felt the need to use itThanks to everyone for the feedback. I''ve come up w/ a good compromise solution which is to only generate the description when it''s actually used. Just required moving the call to generate the description to a different place. Cheers, David