A mysterious optimization in Yanfly Engine Ace - Extra Param Formulas

[Kayzee 3,815]

I found this neat little optimization commented out in my copy of Yanfly Engine Ace - Extra Param Formulas, and it doesn't seem to be in the original version I found on the web:

class Game_BattlerBase
 
  #--------------------------------------------------------------------------
  # mass alias methods
  #--------------------------------------------------------------------------
  alias_xparam = ["hit", "eva", "cri", "cev", "mev", "mrf", "cnt", "hrg", "mrg",
    "trg", "tgr", "grd", "rec", "pha", "mcr", "tcr", "pdr", "mdr", "fdr", "exr"]
  alias_xparam.each { |xparam|
  aStr = %Q(
  alias game_battlerbase_#{xparam}_epf #{xparam}
  def #{xparam}
    base_#{xparam} = game_battlerbase_#{xparam}_epf
#~     @@#{xparam}_n_lambda ||= eval("lambda {"+YEA::XPARAM::FORMULA[:#{xparam}_n_value]+"}")
#~     @@#{xparam}_f_lambda ||= eval("lambda {|n, base_#{xparam}| "+YEA::XPARAM::FORMULA[:#{xparam}_formula]+"}")
#~     return @@#{xparam}_f_lambda.call(@@#{xparam}_n_lambda.call, base_#{xparam})
    n = eval(YEA::XPARAM::FORMULA[:#{xparam}_n_value])
    return eval(YEA::XPARAM::FORMULA[:#{xparam}_formula])
  end
  )
  module_eval(aStr)
  } # Do not remove this.
 
end # Game_BattlerBase

Making lambda's instead of using eval directly? I thought it was a really good idea... so I commented them out, and commented the evals out instead... and it seems to work just as well but makes my game run a hell of a lot better. That may or may not be obverver bias.

 

So I have to wonder... who added that, and why was it commented out? I don't think I did it myself and forgot about it (though it sounds like the type of thing I would do, and I remember wanting to look into using procs for evals, but I don't think I ever worked on it). Anyone else have these lines in their copy of the script?
 

Edited August 26, 2014 by KilloZapit

[Tsukihime 1,487]

That's a pretty cool optimization.

 

I've started a discussion on this over at RMW

http://forums.rpgmakerweb.com/index.php?/topic/31474-formula-optimization-speed-up-your-formula-eval-code/#entry305937

 

Note the issues with your procs: they are stored in class variables. What happens if different instances have their own formulas? For example, suppose you were using this for damage formulas.

Edited August 26, 2014 by Tsukihime

[Kayzee 3,815]

I could have done it myself, but I am not sure if I ever felt that comfortable with lambdas and class variables. And of course, if this was like a damage formula instance variables would be the way to go. I think my original idea for eval optimization was to make a whole new eval function that used a hash look up to match a string to a lambda... but I never really figured out how bindings would work, and I am not sure if string lookup would be any faster. Anyway, I kinda of think damage formula evals are used rarely enough that they aren't terribly important to optimize. These extra param formulas on the otherhand, I have found can be called as part of a loop sometimes.

 

As a side note It also should be noted that ||= is sort of being misused in the code above, since the exact meaning is "x ? x : x = y", which I think is a common mistake and one I have done in the past.  Not really important, but I thought you might want to use it like this in your eval on that post:

def eval_my_formula(formula, v=$game_variables, s=$game_switches, ... )
  ( @myFormulaProc ||= eval("lambda { #{formula} }" ) ).call
end

Edited August 26, 2014 by KilloZapit