Comments

• Henrik N on 04 May 02:40

  This example is definitely not the place for metaprogramming. Even if it would run equally fast, the metaprogramming version of the code is pretty hard to read.

  One thing I think I would change about your code is to make the methods more readable by defining them in terms of one another:

  def week 7.days * self end

  and so on. Especially when it comes to month and year where someone is likely to check the implementation to see just what numbers are used.

• Henrik N on 04 May 02:43

  Oh, and the 364.25 (as opposed to 365.25) in the very first code snippet is a bug and/or typo.

• dohzya on 04 May 03:19

  try to put @amount = amount.isa?(Array) ? amount[0].send(amount[1]) : [email protected] out of the definemethod. It must be compute one time only, not at each call of method... Your can try to replace your @[email protected] by an @eval( "", binding )@ too (more slow one time only)

• Matt Aimonetti on 04 May 20:38

  Matt Jones had a really good post, but my blog indicated that textile was enabled while only Markdown is enabled.

  Here is Matt's post:

  dohzya's comment is on target - the overhead here is in restoring the context (stack frame) that was captured by definemethod, and handling the amount.isa?(Array) case.

  Just lifting the Array case above definemethod fails pretty badly, as the methods don't get defined on Numeric until the end. (Also note: the meta-programming code relies on the TimeDsl code in this example - mdays calls TimeDsl's version of hours)

  What's really needed (if you want to go meta) is something closer to ActiveRecord's method:

  see pastie

  Please look at the above pastie to see how Matt got really good perf using metaprogramming. Really interesting stuff!

• Ben on 05 May 01:00

  I seem to remember a cartoon from the 80s - GI Joe, maybe? - that always had a moral at the end; like the one in this post, however, the moral presented then often seemed to be the wrong one given the experiences the Joe team had in the preceding half-hour.

  Isn't the correct moral here that you should benchmark your code, metaprogrammed or otherwise?

• Matt Aimonetti on 05 May 01:35

  Good point! At least if you care about performances.

  Now, if the benchmarks were close and that the slightly slower version was easier to read/understand, I would probably go for readability over performance.

• allen on 05 May 07:43

  Metaprogramming is used to add methods and features to classes at load time, not on each instantiation. Of course, doing this will require more work to dynamically create and install these methods on your Ruby classes.

  While the metaprogramming can be slower on load time, it it not significant considering it is only loaded once (in the production environment, though after every change to those classes in development).

  This should be the same in merb as rails. In a script/runner invocation or an application off the rails (CGI, command line, etc.) will have a slower load time as the class will be loaded each time your app starts up.

  In the end, it does provide more readable/maintainable and DRY code, if written well. Are you optimizing prematurely?

• DaveS on 05 May 08:06

  You might as well go back to assembly programming...

• Ken Miller on 05 May 08:21

  It's not metaprogramming per se that makes this slow, it's the use of definemethod. methods so defined are always slower to call than methods defined the usual way. If you just use classeval and a string containing a standard method definition, you'll get results more in line with the written out version.

  Of course, then it's even harder to read. Metaprogramming should really only be used if it's the only way to solve a problem, as you say, but performance is not really a reason not to.

• Ken Miller on 05 May 08:27

  Amendment to above: in this case, it's also that you're doing the array work every time. That could easily be moved into the generator code and out of the instance method, leaving the instance methods defined identically to the hand-coded methods.

  But this really supports the overall point -- metaprogramming is harder to write and understand, and contains more opportunities for bugs and sneaky performance pitfalls. But if you really need it, it IS possible to make it perform just as well as hand-coded ruby.

• Tim Harper on 05 May 11:16

  The following code is just as fast, and I would write it this way over the long way :) It's pretty clear to me.

  module MetaTimeDSL SECOND = 1 MINUTE = SECOND * 60 HOUR = MINUTE * 60 DAY = HOUR * 24 WEEK = DAY * 7 MONTH = DAY * 30 YEAR = DAY * 364.25

  %w[SECOND MINUTE HOUR DAY WEEK MONTH YEAR].each do |const_name| meth = const_name.downcase class_eval <<-EOF def m_#{meth} self * #{constget(constname)} end alias m#{meth}s m#{meth} EOF end end

• Tim Harper on 05 May 11:16

  The following code is just as fast, and I would write it this way over the long way :) It's pretty clear to me.

  module MetaTimeDSL
    SECOND  = 1
    MINUTE  = SECOND * 60
    HOUR    = MINUTE * 60
    DAY     = HOUR * 24
    WEEK    = DAY * 7
    MONTH   = DAY * 30
    YEAR    = DAY * 364.25
  
    %w[SECOND MINUTE HOUR DAY WEEK MONTH YEAR].each do |const_name|
      meth = const_name.downcase
      class_eval <<-eof>

• Rob Kaufman on 06 May 13:24

  It is worth noting that Tim Harpers method only gets called when the class instantiates (which is why it is equally as fast) as Matt's cleaned up version. The most important thing about meta-programming is knowing when to use it and when not to and to only do as little as possible. The reasons are speed, readability and maintainability. And remember there is nothing wrong with writing code that writes code (generators)

Comments are closed