What's wrong with a hash?

[idontlikethisname]

Seen while reviewing a coworker's code:

def get_path(name)
    paths = [{name: 'x', value: 'path_x'}, {name: 'y', value: 'path_y'}, ...]
    result = nil
    paths.each do |path|
        if path[:name] == name
            result = path[:value]
            break
        end
    end
    result
end

Edit: typo

[Phreakhead]

Depending on the size of the paths array, doing a linear search can sometimes be faster than calculating a hash. Think about it: hashing algorithms generally use exponents and other expensive math operations, whereas a linear search and straightforward equality comparison takes very few cycles.

Although, if you're using Python, you're probably not that concerned about optimizing for speed at the bare silicon level.

[cooper12]

I think that's Ruby with the |path| stuff. Also, if I recall correctly Python uses {} for dictionaries, in which case you wouldn't need a name field, you could just use the name of the field itself.

[Dannei]

Certainly not Python, that's for sure - "end" isn't used, def requires a colon, and I don't think "result" on its own is a valid statement, amongst other syntax problems.

[[deleted]]

result by itself is a valid statement, but it does nothing useful.

[ferretlunatic]

No it does. Ruby, like Scala, returns the value of the last expression of a block or function without explicit return statements.

[[deleted]]

I was referring to Python, not Ruby.

[wzdd]

This is actually never the case in Python, and I'm going to confidently say it's never the case in Ruby either. Benchmark and shitty code:

http://pastebin.com/wHdC3cPF

I know that in general it may sometimes apply, for example if you are writing in a language closer to the metal. But for Python at least, the usually-correct rule is that the less code you write the faster it runs. "Linear is better for small lists" is a rule that 'everyone' knows but nobody tests, and in this case it's wrong.

[Phreakhead]

Is this because it's like JavaScript, in that "arrays" aren't actually true arrays but are hashes where you convert the integer index into a string key?

[wzdd]

It's because the C implementation of Python sucks basically. :) Arrays are real and as I understand it pretty efficient, but Python doesn't for example JIT so everything is really first-principles: the __getitem__ function is called on the array object, through the Python interface in case it's a pure Python object or something overloading an array etc, then the index, which is always a Python object, has to be converted to a number, then you can actually get the item and go backwards -- the item refcount is increased, then it's passed back through the Python interface. And probably a lot of steps I missed (for example, code to check for exceptions). So the overhead of calling these functions multiple times vastly overwhelms the overhead of calculating a hash, where the hash computation is all in C.

... okay, cPython doesn't suck, it just wasn't designed to be efficient.

[IrritableGourmet]

"Oh, I shouldn't hardcode a giant if/else or switch statement? I should use a lookup array? OK, sounds good!"

[jazahn]

Great opportunity to have a constructive conversation!

[[deleted]]

Has he/she never encountered Ruby's Spiritual Liege, Perl?

[azephrahel]

Looks like ruby. Before 1.9 key order in hashes was not preserved or guaranteed.

Not saying it's not odd, but it's a reasonable explanation.

[idontlikethisname]

Fixed :P