On Thursday, April 19, 2012 5:05:06 PM UTC-7, Rodrigo Rosenfeld Rosas wrote:
>
>
> I don't really think this would make any noticeable difference in real
> code. What is the code of hash_bench.rb? How much iterations is it doing?
>
require 'benchmark'
n = 500000
INITIAL_VALUES = {1=>2, 2=>3, 4=>5}
def e
h = {}
INITIAL_VALUES.each do |column, value|
h[column] = value
end
h
end
def ewo
INITIAL_VALUES.each_with_object({}) do |(column, value), h|
h[column] = value
end
end
Benchmark.bm(20) do |x|
x.report('each'){n.times{e}}
x.report('each_with_object'){n.times{ewo}}
end
> I'm usually concerned more about code readability than negligible
> performance improvements. Whenever I read lines like "h = {}" and "h",
> something doesn't feel right to me, but I agree that this is entirely my
> personal point of the view in the subject.
>
Well, those "negligible performance improvements" add up, and using them is
of the reasons Sequel is faster than ActiveRecord. Personally, I find my
code more readable anyway, though it is definitely less concise.
inject isn't nearly as bad performance-wise (slower, but only by a little),
but I still prefer my explicit approach.
> I've not tested this other style suggestion, but I guess it would work:
>>
>> def initial_value(column)
>> initial_values.fetch(column){send(column)}
>> end
>>
>> def initial_values
>> @initial_values ||= {}
>> end
>>
>> You wouldn't need the fetch with block if you changed initial_values to
>> (again, untested):
>>
>> @initial_values ||= Hash.new{|h, k| send(k) } # or h[k] = send(k), if
>> that is your intention
>>
>
> Using a default proc for a hash should be done sparingly. With your code:
>
> initial_values[:foo]
>
> raises an exception if the instance does not respond to the foo method,
> whereas in my code, you just get nil, which is what most rubyists would
> expect for a hash.
>
>
> But I don't think someone would call initial_values[:inexistent_column].
> If that happens, it is most probably a code mistake and it should really
> raise an exception.
>
Well, you are certainly entitled to your opinion. However, hashes
returning nil for nonexistent items is the default ruby behavior, and
deviating from that should only be done with good reason. With your logic,
model[:nonexistent_column] should raise an exception, but that's not
Sequel's behavior. So in addition to being consistent with ruby, returning
nil instead of raising an exception is also consistent with Sequel itself.
Also, with your method, if you just want to get the cached value, you
> have to do fetch(:foo, nil) instead of [:foo].
>
>
> Do you have any real use case where only fetching the cached value would
> be useful in this particular plugin?
>
Currently, no. I don't have any personal need for this plugin at all
though. :)
Thanks,
Jeremy
>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sequel-talk/-/Lt0xNSpVx2sJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
