1-2% difference is usually not noticeable. I would choose whatever requires the least amount of code and thus is easiest/fastest to read. Code readability is very important when you go back later to add more features or to fix bugs.

Of the code examples you provided I’d say the first is easier to read because there is less text in total and the code is divided into smaller chunks. You can very easily see what entities are iterated before having to care what are later done to those entities. For this example the difference isn’t very big but it’s good to form a habit of writing as readable code as possible when making larger projects.

Btw, when using methods that atke arguments such as is_a? it is recommended to have parenthesis around the arguments. This makes it slightly faster and easier for the brain to parse the code. Again, it’s not a huge difference but when the codebase is getting bigger all these small things add up.

the keywords or and and are not recommended in Ruby since their priority can be quite unexpected. Also I wouldn’t use multiple rows for a condition since you could then easily read part of the condition as a part of the code block. For this example I would extract the condition to a separate method.

if is_instance?(entity)
# Do stuff
end
def is_instance?(entity)
entity.is_a?(Sekcthup::Group) || entity.is_a?(Sketchup::ComponentInstance)
end

I heartily share this sentiment, with one caveat: by “least amount of code” I would mean the simplest, cleanest expression vs multiple things packed onto each line. Packing onto a line has a tiny effect as the interpreter parses the code, but no effect at all on run time. But, at least in my experience, it makes it harder for a human to understand the logic. I always choose ease of reading over terseness, provided of course that the expressions are equivalent. Many logic errors result from trying to be too terse or clever!

You are getting into stylistic issues so we will have to agree to disagree. I do use parenthesis around if statements etc as I find them very much easier to speed read and maintain.
I certainly agree that adding parenthesis to all methods helps the brain to learn.

I use the c style && instead of and and I use || instead of or. It speeds readability and there is no confusion on precedence.

I use single quotes for string literals when possible. It is slightly faster than double quotes as the parser doesn’t have to take the time to look for escaped characters etc. Having said that I do make use of << for string concatenations and “#{}” instead of printf style.

I also break up long conditional statements on to multiple lines and I create references to objects.

ents = Sketchup.active_model.entities

ents.grep(Sketchup::Face) { |ent| puts ent.entityID }

Having said that Additionally when workable I like to have case statements on the same line where possible and I do make use of white space not tabs to line everything up. If you are sharing code spaces always line up - tabs only line up if the reader has their tab settings set the same as you.

For actual profiling, of digging into a call stack and see what is using the most time I’ve been experimenting with the RubyProf gem. But it’s been a pain to get working because it need compiling. Additionally it stopped working properly in recent SU versions so I had to hack it to get useful data. Been hoping to get time to package up this into a SU tool.

When trying to benchmark code, I would try to remove any IO code, as its duration/timing may be longer than the code under test. Obviously, IO to a hard drive will be slow, but puts is also IO. Said simply, having a puts in your blocks invalidates the test results.

I believe timing resolution varies by OS, and Windows may only be 1 frarme, or 1/60 second (ruby trunk may change this, as to backports to 2.4 or 2.3, unknown). Multiples of 0.0156 are the give-away…

Timings vary, which is the reason most tests using benchmark perform the tests many times.

Generally, most methods for selecting from collections will be pretty close as to time, and whatever other code you’re using (ie, code interacting with SU objects) will probably be where the optimizations can occur. Complex calculations may also require optimization.

Below is some code I used to check some selection methods (changed to compact it)…