Optimizing Script Speed/Efficiency

[regi]

Note: this is more of a discussion type thread than support, so feel free to chime in with something new!

What are some tips for creating the most efficient codes, and what problems/solutions do you often face in your scripting endeavors (e.g. lag)?

An example I come across often is the "for event in $game_map.events" loop. I believe it can induce a bit of lag on maps with a lot of events, especially when multiple loops are used to check different conditions. Some possible solutions include moving the code to class Game_Event instead (although this is sometimes unavoidable), or perhaps adding all affected events to an array in the beginning that meets the condition, and only modifying these events later (thus only running through the loop once, rather than every update). Of course, if the events are changed, the array will have to be modified again.

Any feedback from those scripting gurus out there?

 

[BlueScope]

First off, if you use the each methods, you're in general better off performance-wise, though you sometimes have to use a for loop because, for example, you need an index for y-alignment (aka draw element array at [0, i * 32]).

The obvious advice that global variables should be avoided is something you sure know. You might also know that this applies for all the other variable types as well, just less drastic. Means, whenever you can use a local variable - do so (as I said, guess you know that - just mentioning it for completeness' sake). Constants are something that equally eat up your performance, mainly if you reassign them during runtime (which for some reason, you're allowed to in Ruby) - if they make sense, they're the best solution you can get, otherwise try to find a substitute for it. Try to avoid stuff like this:

Constant = 'foo'

 

def initialize

  @foo = Constant

end

There's several little things you can optimize, such as not aliasing everything, but packing it directly in the respective methods, as aliases chew a piece of performance the way they work.
Only creating methods for features you really need seperate is another thing to pay attention to, so don't do something like this:

def initialize

  @foo = 'foo'

  initialize_bar

end

 

def initialize_bar

  @bar1 = '1'

  @bar2 = '2'

end

If you really want to go nazi about optimizing, note that even comments are read by the interpreter, so if you have a huge block of instructions, you might experience a frame of lag or so. It's really nothing too big to fuzz about. ^^


In general, there's lots of things I didn't mention now, simply because it heavily depends on your script what you can and cannot do.

 

[Atoa]

An example I come across often is the "for event in $game_map.events" loop. I believe it can induce a bit of lag on maps with a lot of events, especially when multiple loops are used to check different conditions. Some possible solutions include moving the code to class Game_Event instead (although this is sometimes unavoidable), or perhaps adding all affected events to an array in the beginning that meets the condition, and only modifying these events later (thus only running through the loop once, rather than every update). Of course, if the events are changed, the array will have to be modified again.

This principle is used on Zeriab anti lag, and on the ones i made (after seeing that zeriab do this on his, although the method is a bit different).

In RM you shouldn't need to worry a lot about performance of certain codes and methods unless they're absurdely time consuming or called on updates.

Things that you should avoid by all meas:
- refreshing windows during updates (a mistake that is common to see in Map Hud scripts)
- Adding big loops on updates (if necessary, try to optmize de loop, by adding only items that will surely needs updates, and removing the ones that don't need)
- Drawing text every frames. (Draw text is quite slow)
- Drawing bitmaps every frame. (The same as above)

In the case of bitmaps, you can store them on instance variables when you need to blit them in windows.
Instead of:

def refresh

  self.content.clear

  bitamp = RPG::Cache.picture('image name')

  self.contents.blt(x, y, bitmap, Rect.new(a, b, w, h))

end

you can store the bitmap on an instance variable during initialize and

def initialize

  super(x, y, h, w)

  @bitamp = RPG::Cache.picture('image name')

end

 

def refresh

  self.content.clear

  self.contents.blt(x, y, @bitamp, Rect.new(a, b, w, h))

end

In general, only methods and big loops called on updates can cause noticable performance lost, except by a few time consuming methods.

 

[Phoenixia]

Here's a couple of useful things:

1.) "and" and "or" evaluate to false/true as soon as they hit a false/true conjunct/disjunct; so,

x.a? and x.b?

will be faster than

x.b? and x.a?

if it is more likely that a comes up true over b for x. Of course, you also need to consider the cost of evaluating a and b on x, but the same reasoning applies when one is more expensive in terms of time.

2.) Do the same as above when using if/elsif -put the cheapest first, then next cheapest second, etc.

3.) Avoid multiple calls to a calculating method. So, given:

def calc_something(val)

     Calculate Stuff and return

end

 

def method1

     return calc_something(5) if calc_something(5) > 0

     return -3 * calc_something(5)

end

 

def method2

     x = calc_something(5)

     return x if x > 0

     return -3 * x

end

 

method 2 will be faster. Granted the example isn't the greatest, but its easy to do more subtle forms of this.

4.) Don't use hashes unless there is a really good reason, especially if you need to iterate over the whole collection; arrays are just more efficient.

5.) Use destructive operators (the one's with a !) when possible since they don't waste time duplicating whatever you're acting on.

6.) Avoid using fancy code because it looks fancy -there are a lot of really "smart" looking ways of doing things that involve complicated logic, most of the time this does not translate to more efficient.

7.) Finally, weigh the algorithms you know against what you are using them for -some algorithms might have a really good worst time complexity, but not a great average time complexity; or, sometimes, there may be a fast general purpose algorithm for what you are doing, but for the specific data you have, an overall worse algorithm might be better. In that same vein, it is usually better to calculate to within 90% accuracy in 1 unit of time than it is to calculate with 100% accuracy in 20 units of time.

 

[regi]

These are all pretty helpful pieces of advice! I'll definitely keep them in mind.

Just thought of a random question: is there any difference between:

def method1

   do_this

end

 

def method2

   do_this

   do_that

end

and

def method2

   method1

   do_that

end

?

 

[Phoenixia]

Yes, the code in the second example is slower. Here's why, every method, variable, etc. is stored in a syntax tree, so when you call a method from another one, Ruby must search through the tree to find it. For this reason, calling anything that isn't in the immediate method's scope will cause a hit in efficiency; though this hit is not going to be too drastic, so it may be better to split into multiple methods for simplicity. So, calling a method from inside a method will have little effect in one spot; but the more you do it, the more methods over all, thus, everything runs a little slower.

On a side note, I thought of two other little optimizing things while responding:

1.) Using single quotes will make strings work faster than using double quotes. Also on strings, it is faster to use inerpolation over concatenation.

2.) You can make assignments in loop while/until conditions to cut back on method calls, example:

def thing1(val)

     do stuff to val and return the result

end

 

def method1(val)

     until thing1(val) == 0

         val = thing1(val)

         do stuff

    end

end

 

def method2(val)

     until (val = thing(val)) == 0

          do stuff

     end

end

method2 will be faster since method1 has to call thing1 twice and method2 only needs to call it once. This is useful if, say, you are slicing characters off of a string and waiting for it to return the nil character, as in:

until ((c = str.slice!(/./m)) == nil)

     do_stuff(c)

end

Or if you are using thing1 to setup some sort of recursive calculation.

 

[Atoa]

@regi
there difference, but they're totally irrelevant. We're talking about nano-seconds difference, and this totally unnoticeable.

Another thing i might add: FileTest.exist?(filename) is also damn slow. At the point of dropping FPS by 5 if you have a couple of it on an update.

@Phoenixia
Although all you said is true, most of them fall on the same situation I said above: "We're talking about nano-seconds difference, and this totally unnoticeable." So why worry?

People shoudn't be excessively worried about it when programing codes for rpg maker, unless we're talking about noticeable performance loss.

 

[Phoenixia]

For the most part, you're right, there is no real need to worry about such optimizations for the point of speed. However, it is not hard to be aware of these and integrate them into how you code, nor are they horrible in terms of readability and simplicity (I don't think they effect such things at all). But more importantly, they can have substantial impacts depending on what exactly you're doing. For example, it is pointless to use interpolation over concatanation for printing simple messages to the screen, on the other hand, if you are using a string to do calculations, then it may become quite important.

Actually, a good example might be enemy AI. Suppose that you are using the if/elsif construct in your AI, some conditions might be much harder to check than others; so you should definitely be concerned with the order you are evaluating them in.

I can think of about ten more general cases where the above optimizations would be valuble. The point is that you can't guess what somebody will be coding and how, so you can't say ahead of time that something is pointless because they would seem so in the obvious situations. Indeed, by being selective you can make any optimization seem pointless; memoization is a good example of this, so is recursion (when did you last use recursion to do multiplication?)

Also, thinking about how you're coding and what's going on behind the scenes can be very useful to the person programming. Someone who regularly considers such things is, probably, going to end up outputing better code, in the long run, than someone who doesn't (and you say we shouldn't worry if it's for rpg maker, but how many people here have learned to code just for rpg maker?)

Finally, I return to my original point: why not factor in the above methods to your coding style if it's just as easy as your current methods and can net you decent gains some of the time?

*I realize my wording above makes it sound like I'm saying recursion is an optimization, this was a bad choice on my part, but the point is still a good one. Oh and

 

[BlueScope]

Finally, I return to my original point: why not factor in the above methods to your coding style if it's just as easy as your current methods and can net you decent gains some of the time?

Yep, that's pretty much what I said in another topic where noone agreed with me :blank: And I definately agree that it would eventually increase the person's handling of code by knowing the gears behind it.
What I don't really agree with is the part where you said people don't usually learn coding to work with RPG Makers - as far as these forums go, I'd definately concur. Nevertheless, in my opinion that makes it even more important to communicate "pay attention to coding even when it's not needed, in case you want to switch to a more serious development platform later", instead of "do what you want, because everyone else doesn't give a fuck either".

Also, the topic says "most efficient code", not "good enough for the average mapper not to notice anything wrong with it".

 

[Phoenixia]

I completely agree with you, the whole point of coding should be to put out efficient logical code; good code is beautiful, poor code is ugly and doesn't inspire new ideas.

By the way, rereading my parenthetical, my choice in words was poor; I was trying to say that a lot of people in the community probably did learn to code for rmxp; but I can see why it would sound like the opposite.

If this post seems sparse, it was written walking out to my car on my phone.

 

[Atoa]

Finally, I return to my original point: why not factor in the above methods to your coding style if it's just as easy as your current methods and can net you decent gains some of the time?

Are they really easy as the other methods? it's totally relative. What some people think is easier, other people think is harder. (Some people think that making a HUD is godly hard, and anyone here agree that it's absurdely easy)

What i think is: if both are as easy, and the impact on performance are irrelevant, why bother changing? I don't see a point in changing something that already works properly and satisfatory, just for the sake of perfection.

For me what matters is the final result, and if it's works and don't have noticeable losses, i don't care about what codes was used. As long there's no noticeable loss, to hell with it xD

 

[Phoenixia]

Some people think that making a HUD is godly hard, and anyone here agree that it's absurdely easy

I'm talking about writing code in a proffessional way, not what types of things are hard to code. If you find coding in a proffessional way that uses a language like it should be used hard, then that confuses me. Not to be rude, but failing to pay detailed attention to your programming style and the choices you make is like chosing to talk exclusively in slang terms; sure, people would understand you, but that's not the point.

the impact on performance are irrelevant

How are you reaching this conclusion? Sometimes there are very meaningful gains. But more importantly, if you can look at your code and say all of this stuff is irrelevant, then you must have been thinking about all of this to know that it doesn't apply. Or do you mean to say that you find it irrelevant? That's fine, if so, but code can be used in a million different ways.

For me what matters is the final result, and if it's works and don't have noticeable losses, i don't care about what codes was used. As long there's no noticeable loss, to hell with it xD

No offense, but this makes me feel sad :sad: How can you not care about the code you produce when you are writing code. I'm sure you see yourself as producing functionality, but that's like a chef saying he doesn't care about the quality of his ingredients, only the end result. If you are going to make something with good function, why not build it with quality? Would you drive a fancy looking car with garbage parts under the hood?

Maybe I'm misunderstanding and I don't mean to sound so nasty in tone, but your view point is so much the opposite of mine that it is confusing. Not that you aren't entitled to it, I just doubt we'll ever see eye to eye on the matter. Again, sorry if I sound overly rude Have a good day

 

[Atoa]

How are you reaching this conclusion? Sometimes there are very meaningful gains.

By the simple practice. If there's no slowdown/lag/FPS drop during gameplay.
As i said MOST of the things (not all), things like using ' instead of " for strings. This will never, ever make a noticeable performance loss on gameplay and you didn't mention the difference between both, for those who don't know, try to use eval('p #{$game_variables[1]}').

No offense, but this makes me feel sad :sad: How can you not care about the code you produce when you are writing code.

For me the code is the way to reach the result, and the important is the result. I don't give a danm to the code as long it works properly and satisfatory.

If you are going to make something with good function, why not build it with quality?

Quality is also relative, and i never said i do thing with bad quality on porpouse, but i won't go crazy trying to make things absolutely perfect, if it's not necessary.
Some of the examples that was given here would increase the performance, but could induce people to errors (since no one told the drawback of the changes) or would make them less user friendly. Like the Constant example made by Blue Scope, Using constants on an outside module slower? Yes, but it's unquestinable better for make script settigs, so user can change them at ease, the same with hash/array. hashes may be slower but are better to deal than arrays, since the order doesn't matter.

The question brought by regi is the same situation, this will never cause an noticeable performance loss, and for RM, in most cases it's BETTER to do on the slower way, so you can have a separate method with an give code that is used in various places, that way, if you need to make changes on that given code. In fact this principle is used on RGSS2. On RGSS the methods was given as a whole, wich is like the example 1, on RGSS2 the methods was sliced on smaller methods.

For me Max Efficiency isn't everything, balance is the most important.

The point is that people on this topic are only showing one side of the coin. Some of the hints here are invaluable, but anothers are relative, as they can't be set in stone, and can't be applied always.

What are some tips for creating the most efficient codes, and what problems/solutions do you often face in your scripting endeavors (e.g. lag)?

By this i think he want tips to avoid noticeable performance loss (e.g lag), most of the thigs mentioned will never cause lag in a game, so why bother?

 

[Phoenixia]

I agree with you as pertains to some of the optimizations I mentioned above, my disagreement is more in a general sense. I think people should be aware of all the little things, then they can chose how exactly to implement them. I don't think that you should do a detailed analysis of probabilities to deal with every disjunction, however, I think that the consideration of doing it should flicker, however, briefly in the back of your mind that you could do it and how you might do it, or why you might want to do it. A lot of times these 'flickers of optimizing' have helped me to write better code; if every couple of lines I'm noticing a way that I could improve things, then I begin to look for a better way in general to solve the problem at hand.

There is also another reason I think that knowing these things is important: they educate you about what lies beneath the language's layer of abstraction. This may sound like an overly academic thing to care about, but it isn't, anyone who is serious about coding will, eventually, find holes in this abstraction, they will need to understand how the language functions behind the scenes to do what they want. For example: lumping everything into one method destroys the whole point of methods for little speed gain, however, knowing that there is a difference and why informs you on how things work in Ruby. This extra information can be of great use if you wanted to modify how Ruby works or do various other things.

Granted, there are other ways to learn this info (just look it up), but every little bit of knowledge helps to unify your understanding, which will make you better at what you are doing.

Also, I came here to discuss optimizations in speed, not every optimization is in speed, you can optimize readability, memory use, reusability, effectiveness, generality, etc. In other words, I do think that all of the tips I mentioned should be factored into how you think about coding, but I also think you should factor in the other couple hundred of tricks pertaining to other areas -and not everyone will be applicable so, yes, you will have to strike a balance between them in some fashion.

So, in conclusion: I'm not advocating that everybody go through all their scripts and change " to ' everywhere it shows up; What I am advocating is that when people are writing a path finding script using a hash with [x, y]'s as keys [coordinates] that they stop and realize how replacing it with an array would make it cause less lag -or, better, never consider using the hash in the first place because they understand ahead of time that it would suck.

*I think we may have been arguing two different arguments; this was probably my fault, I moved from talking about specific optimizations to a much more general conception and point assuming it was clear that I was.

**Still, this:

For me the code is the way to reach the result, and the important is the result. I don't give a danm to the code as long it works properly and satisfatory.

I can't agree with you on. I'm not trying to be an ass by pointing it out, this just goes against most of my personal philosophies and I feel compelled to not look like I agree with it. Yes, I'm kind of weird, but I truly don't mean to insult

***It's been many many hours since I slept, so if something sounds like nonsense or doesn't jive with what I'm saying, be charitable and assume I'm not an idiot.

****Since I feel sleepy and like what I said was unclear, you should just defer to what Blue Scope said below as that's pretty much what I'm thinking. Night all

 

[BlueScope]

Some of the examples that was given here would increase the performance, but could induce people to errors (since no one told the drawback of the changes) or would make them less user friendly. Like the Constant example made by Blue Scope, Using constants on an outside module slower? Yes, but it's unquestinable better for make script settigs, so user can change them at ease, (...)

The last thing I'd call it is 'unquestionable'. In fact, it's probably what I question the most in nowadays released scripts. It encourages lazyness, disinterest in code for the simple lack of need to look at it, and that is all long before the performance reasons. Also, it's not only the constants itself, but countless explanations often coming with it, while a not-even-too-much experienced scripter can easily tell what variables do by their usage directly from the code, if not by the name alone. All of that impedes readability, and therefore makes for bad coding style, as readability is a mark of good coding style, in my opinion.

(...), in most cases it's BETTER to do on the slower way, so you can have a separate method with an give code that is used in various places, that way, if you need to make changes on that given code.

Actually, what you're talking about is the more efficient way, as it results in less code by using the same segment for multiple methods.


As for the general question... yeah, in theory, as long as code works, it's kind of good. Still, there are some things to clean and neat coding style that shouldn't be ignored just like that:

• clean, structured code is easier to read, therefore easier to follow, meaning people will have an easier time learning from it - I don't know about you, but back in the days when I first learned scripting, I was glad about every damn slice of understandable code, opposed to the usual glibberish thrown out by people who 'just care about the final result'
• good readability results in yourself having an easier time working with code, especially in the long run
• efficient code is faster, making for smaller file size. Now, I'm pretty sure most people here will say it's no different whether your scripts result in a total of 100 or 105kB, but that heavily concurs with the general idea of programming, where people actually go .tar.gz on 5kB files. Scaled up, that can result in complaints from your customers, which is what happened to Adobe: Photoshop went from a couple of MBs to multiple hundrets, and like many others, I wonder whatfor. So yes, they still sell their software, but ultimately, reputation will matter as well - remember that one FPShooter with just a handful of MB, still featuring state of the art graphics by utilizing most efficient code.
• coding efficient will make yourself try and find more sense-making solutions, resulting in less cluttery scripts in the end. Again, I know that lots of people will now say that what they're working on doesn't have more efficient solutions... and yeah, guess what, if you would'Ve figured them out, you probably wouldn't have done it this way. From my experience of pointing out quite obvious (at least to me) flaws in peoples concepts over the past years, I'd say it's much underestimated). Looking at lots of the old scripts of dubealex and Near, I think many people will find things to improve, now that there's lots of new ways to handle stuff around, and people know what's to do.
• If it's worth anything, it'll make you feel like a more accurate programmer in the end. From my own experience, I had more fun working with things I felt more experienced at in the past, no matter what, and coding not being the exception at all.
• Oh, and you won't get made fun of once you take a step out of .org, into the world where coding style actually matters.

As for regis question: To my understanding, it clearly says "show me the most efficient way", not "show me something that makes me believe I script efficient".

 

[Atoa]

I think people should be aware of all the little things, then they can chose how exactly to implement them.

That's exactly the point, on you examples, you showed only reasons for them to use the hints, but not the reasons that goes against it, again the example of the string (yeah here we go again), a ' is faster, so someone take a look on the topic and have the bright idea: i will replace all doube " with single '. He will do it and in the end he will get errors, because both string signals works differently. If you stated the difference, pros and cons of each option it would be better for everyone.

I most part of this topic, the hints are like "do like this, because i'm telling that it's better", it would be better if they had the explanation of why they're better, along with some considerations of their aplications, since some of them aren't simple replaces.

It encourages lazyness, disinterest in code for the simple lack of need to look at it, and that is all long before the performance reasons.

I disagree with this, some people don't make script to make people become programmers, neither do them to people that are already programmers, they made them exactly for people that DON'T have interest/capacity to leanr RGSS.
I personally hate lazy people, but just because someone choose to not become a expert programmer that don't mean that this person is lazy.
At the same point i don't make scripts to serve as tutorials. If someone want to study RGSS, there's a lot of ways. I make the codes for myself, and the results for the others.

In fact i prefer that people mess the less possible with the code, that way it's easier for me to make updates and such.

If it's worth anything, it'll make you feel like a more accurate programmer in the end.

For me this is worth nothing, I do not program to boost my self-esteem. It's already great : D

Oh, and you won't get made fun of once you take a step out of .org, into the world where coding style actually matters.

I don't know about the others, but i don't give a damn to other opinions about my style, no matter if it's the style of my clothes, of my hair or of my codes, it's my style, and if someone makes fun of it... to hell with them ;D They don't pay my bills so a don't owe nothing to them.

I don't make my codes to show of the quality of the coding, but to show the quality of the function it was supposed to do. As long the quality of the function is unaffected in a noticeable way, i don't care.

I can't agree with you on. I'm not trying to be an ass by pointing it out, this just goes against most of my personal philosophies and I feel compelled to not look like I agree with it.

You don't have to agree with me, it's just my opinion. That's the fun part of dicussing, if everyone agreed with everything it would be really boring.
As long we don't insult anyone it's ok. and you don't insult me by disagreeing with me '-'/

 

[regi]

Well both of you have brought up great points regardless of your differing opinions! I do agree with both of your points: imo you should keep a habit of coding efficiently, no matter how little the difference; but at the same time, be aware of the important differences (e.g. when ' cannot replace ") so you don't fall into those traps.

(Just a sidenote: this has to be the friendliest debate this forum's seen in decades :thumb: you guys are great)

 

[BlueScope]

@Atoa: I'm not trying to say everyone's scripting to show others how it works... of course, the majority will give a damn about the code and just shove it in their projects, adjusting a constant or two and never look at it again. Now I know my comparison to real-world game design aren't always apprechiated here, but just for fun's sake, imagine that happening in a real development environment: Lead designer says that what they need is definately a communitcation script for players to interact with each other over IRC while playing. Lead Programmer goes on the internets, gets the first best script for the purpose that sounds the most fancy and has the most features, downloads it and shoves it into the project, with maybe making a note in the credits doc. Noone ever double-checks it, and everyone's happy with the quick fix until it's release day and everyone in the team is surprised by reviews saying that "the game's great, but it would be even cooler with a chat system that could take more than 4 people at once without crashing :/".

If you have no idea about code, and therefore cn't check the scripts, well,... learn it. You're not attending a triathlon when you cannot ride a bicycle either. Nt having the interest or capacity to learn RGSS is an excuse for being lazy, or simply means you want to make a game but don't really care about the outcome, in which case it will reflect in your game's quality anyway, ultimaely making it not worth to be done. It's like me saying 'I don't have the interest or capacity to learn English, so you better live with German texts in my game - have fun!'

• reponsible game makers should always, no matter what, with no excuse whatsoever, double-check the scripts they put in their projects.

Second, you are releasing source code, which means a shard of all the people using the script will actually look at the code, trying to learn from it, whether you want it or not, and definately without you being aware. If that wouldn't have happened, we wouldn't have so many scripts utilizing the SDK-way of naming aliases, or the constants for the oh-so-efficient customization. If you know how to read code, you can look through it and modify it accordingly, without the need of any constant. Performance, code expertise (on the user's side) and code length will all benefit from that, as well as code familiarity, which I tried to explain above.
Guess what, when I started scripting, that's what I did. Without knowing eve what the stupid symbols in front of the variables do. I was still able to read @variable as a variable, and translate it's name to it's function, and then change the number behind it to get what I wanted. The general RM user would not be so darn code-foreign if the scripting community wouldn't have made them that by releasing scripts that don't need any effort on their end.

• If you release code, be aware others will eventually look at it. If you're aware of that, try to not become the reason why all of a sudden everyone scripts like there's no tomorrow.

And heh, what I meant with code style being made fun of was referring more to how others see your style outside of RM communitites. Whereever I've been, people care a lot about clean coding. It's like going to the fantasy forest every day, seeing beautiful colors and random animals, just to come back home to .org in the evening and get reminded how lazy, uncaring and overall disinterested people can be around stuff. Well, not taking the mapping and graphics part into consideration, of course
That naturally leads me to the conclusion that whereever you'd go with an RM comunity coding style, you'd get crucified for exctly those reasons. And you know what, that place could just as well be someone paying your bills, which is what happened to me.


Now the thing is, the way it is works fine for people, I suppose... when noone realizes what they could have instead, everyone is happy. It's apparently worth taking effort in graphics and not in scripting efficiency according to the public, so I guess I will continue my guerilla fight of once in a while attacking a patrol somewhere and vanishing again as fast as I can XD But yeah...


@regi: Yeah, it indeed is a friendly debate... must be all the "in my opinion"s I scattered Nah, seriously, it's one of the debates where everyone stays at reasonable arguments instead of turning it into personal vendettas, ilogical reasonings or whatnot.

 

[zeus81]

If you're still interested :
hash.keys.each slower than hash.each_key (idem for values)
string == "" slower than string.empty?
def a() return b end slower than def a() b end (not very significative)

In other side some built in methods are slower than code :
array.each_with_index do |o, i| slower than array.each_index do |i| o = array
i, j = j, i is way slower than k = i; i = j; j = k
i.between?(j, k) slower than i >= j and i <= k (not very significative again)

And a last thing that we can often see which is very slow : a = [b, c].max
It's far better to create a function that compare the values :
def Math.max(i, j) i > j ? i : j end
a = Math.max(b, c)