Project

General

Profile

Actions

Misc #10754

closed

Tiny optimisation of Set#include?

Added by ismael (Ismael Abreu) over 9 years ago. Updated about 9 years ago.

Status:
Closed
Assignee:
-
[ruby-core:67664]

Description

Hi!

I'm not sure if this a relevant optimisation but here it goes. A simple way to improve Set#include?
I don't think there should be any side effects with this change.

Here are some dummy benchmarks https://gist.github.com/ismaelga/68bb3ea51b4742f65699
They are not consistent, but that should be because of garbage collection or something. Right?

I've also sent a Pull Request: https://github.com/ruby/ruby/pull/810


Files

patch.diff (544 Bytes) patch.diff ismael (Ismael Abreu), 01/18/2015 01:18 AM

Updated by normalperson (Eric Wong) over 9 years ago

This speedup probably happens because Hash#[] has an optimized dispatch
VM instruction (opt_aref in insns.def) while Hash#include? does not.

Seems like an OK change to make, I'll commit in a few days unless others
raise objections.

Updated by ismael (Ismael Abreu) over 9 years ago

With the benchmarks I've run I noticed that sometimes rarely, the old include? was faster.
Do you have any idea why is that? The only cause I can think of is the GC.

Updated by normalperson (Eric Wong) about 9 years ago

I didn't notice the old code being faster, and I don't see your
benchmark triggering GC. Perhaps it is related to memory size
(swapping or CPU cache misses) or power management
(CPU clock frequency adjustment, "turbo boost", etc...)
Modern hardware is tricky to benchmark :/

Updated by ismael (Ismael Abreu) about 9 years ago

Any update on this?

Updated by normalperson (Eric Wong) about 9 years ago

Thanks for the reminder, I got distracted with other stuff :x
Committed r49568

Updated by ismael (Ismael Abreu) about 9 years ago

Awesome! :)

Shouldn't this issue be closed also?

Updated by marcandre (Marc-Andre Lafortune) about 9 years ago

  • Status changed from Open to Closed
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0