[Rails-core] [Feature] Add support HashWithIndifferentAccess to Hash#extract!

[Andrey Molchanov]

Hello there!
I propose to add support for class objects *HashWithIndifferentAccess* to 
method *Hash#extract!*:
before:

def extract!(*keys)
  keys.each_with_object(self.class.new) { |key, result| result[key] = 
delete(key) if has_key?(key) }
end

after:

def extract!(*keys)
  keys.map! { |key| convert_key(key) } if respond_to?(:convert_key, true)
  keys.each_with_object(self.class.new) { |key, result| result[key] = 
delete(key) if has_key?(key) }
end

Thanks! 

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Question

[Andrey Molchanov]

Hello there!
What do you think about to inherit classes *ActionView::Template::HTML* and 
*ActionView::Template::Text* from a common class and extract similar 
methods?
Thanks!

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Timestamps in migration

[Andrey Molchanov]

Yes, in 4.2.5 it is. But after rake db:migrate I not seen it. This behavior 
is strangely. This confused me, and so I created this topic.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Timestamps in migration

[Andrey Molchanov]

Thank you, I will be more attentive

вторник, 5 июля 2016 г., 22:08:31 UTC+3 пользователь Rafael Mendonça França 
написал:
>
> Yes. And I think in Rails 4.2 it show a deprecation warning to tell people 
> that it is going to default to null: false in Rails 5
> ​
>
> On Tue, Jul 5, 2016 at 4:07 PM Andrey Molchanov <neo...@gmail.com 
> > wrote:
>
>> My bad. Yes, it is. But in 4.2.7 it is`n. You specify not add it in 4s 
>> versions?
>>
>> вторник, 5 июля 2016 г., 22:00:37 UTC+3 пользователь Rafael Mendonça 
>> França написал:
>>>
>>> I think this is already the default in Rails 5. Isn't?
>>>
>>> On Tue, Jul 5, 2016 at 3:52 PM Andrey Molchanov <neo...@gmail.com> 
>>> wrote:
>>>
>> Hi there!
>>>> If we create migrate with
>>>>
>>>> t.timestamps
>>>>
>>>> it will add lines
>>>>
>>>> t.datetime "created_at"
>>>>
>>>> t.datetime "updated_at"
>>>>
>>>> In schema.rb file.
>>>> What are you think about if *by default* in this case null option will 
>>>> be false without explicitly specifying?
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Ruby on Rails: Core" group.
>>>>
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to rubyonrails-co...@googlegroups.com.
>>>> To post to this group, send email to rubyonra...@googlegroups.com.
>>>
>>>
>>>> Visit this group at https://groups.google.com/group/rubyonrails-core.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rubyonrails-co...@googlegroups.com .
>> To post to this group, send email to rubyonra...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Timestamps in migration

[Andrey Molchanov]

My bad. Yes, it is. But in 4.2.7 it is`n. You specify not add it in 4s 
versions?

вторник, 5 июля 2016 г., 22:00:37 UTC+3 пользователь Rafael Mendonça França 
написал:
>
> I think this is already the default in Rails 5. Isn't?
>
> On Tue, Jul 5, 2016 at 3:52 PM Andrey Molchanov <neo...@gmail.com 
> > wrote:
>
>> Hi there!
>> If we create migrate with
>>
>> t.timestamps
>>
>> it will add lines
>>
>> t.datetime "created_at"
>>
>> t.datetime "updated_at"
>>
>> In schema.rb file.
>> What are you think about if *by default* in this case null option will 
>> be false without explicitly specifying?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rubyonrails-co...@googlegroups.com .
>> To post to this group, send email to rubyonra...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Timestamps in migration

[Andrey Molchanov]

Hi there!
If we create migrate with

t.timestamps

it will add lines

t.datetime "created_at"

t.datetime "updated_at"

In schema.rb file.
What are you think about if *by default* in this case null option will be 
false without explicitly specifying?

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Increase performance

[Andrey Molchanov]

Xavier, do you want find another similar place for changes?

суббота, 7 мая 2016 г., 20:47:59 UTC+3 пользователь Andrey Molchanov 
написал:
>
> Oh, of course use until is better
> Yes, I would create PR.
>
> суббота, 7 мая 2016 г., 20:44:30 UTC+3 пользователь Xavier Noria написал:
>>
>> Agree, this alternative reads better, and both options return nil.
>>
>> Alternatively you could use until and leave the condition positive:
>>
>> until node.equal? NULL
>>   yield node
>>   node = node.parent
>> end
>>
>> Would you like to volunteer a PR? (Please /cc @fxn if you do.)
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Increase performance

[Andrey Molchanov]

Oh, of course use until is better
Yes, I would create PR.

суббота, 7 мая 2016 г., 20:44:30 UTC+3 пользователь Xavier Noria написал:
>
> Agree, this alternative reads better, and both options return nil.
>
> Alternatively you could use until and leave the condition positive:
>
> until node.equal? NULL
>   yield node
>   node = node.parent
> end
>
> Would you like to volunteer a PR? (Please /cc @fxn if you do.)
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Increase performance

[Andrey Molchanov]

Guys, thanks you!
And to close subject the last question. What do you think about this 
replace:

loop do
  break if node.equal? NULL
  yield node
  node = node.parent
end

to

while !node.equal? NULL
  yield node
  node = node.parent
end

In this case readability and speed are higher. 


суббота, 7 мая 2016 г., 10:25:08 UTC+3 пользователь Xavier Noria написал:
>
> Exactly.
>
> On Saturday, 7 May 2016, Allen Madsen <allen.c...@gmail.com > 
> wrote:
>
>> I believe what Xavier means is that you need to demonstrate at the
>> places where you would do the replacement that the speed up is worth
>> the readability cost. If on a single request, that code executes once,
>> it's probably not noticeable. That's why in the benchmark you need to
>> run it 100 million times. If you can demonstrate that the place
>> containing the `loop` is a hotspot that gets executed many times in a
>> request, then the optimization is probably justified. That's why it
>> wouldn't just be a find and replace for all instances.
>> Allen Madsen
>> http://www.allenmadsen.com
>>
>>
>> On Fri, May 6, 2016 at 7:47 AM, Andrey Molchanov <> wrote:
>> > Thanks for your feedback.
>> > I agree with you about use idioms for better readable code. Its cool, 
>> but
>> > Rails has many places where this not use. A lot of code can be corrected
>> > according to this, but this is not done.
>> > And I thought, why not use it in favor of speed?
>> > That is what I was based when wrote this message.
>> >
>> >
>> > пятница, 6 мая 2016 г., 14:31:40 UTC+3 пользователь Xavier Noria 
>> написал:
>> >>
>> >> In general, the Rails code base wants to use Ruby idiomatically.
>> >>
>> >> loop is the most succinct idiom in Ruby for those kinds of loops, see 
>> for
>> >> example:
>> >>
>> >>
>> >> 
>> https://github.com/rails/rails/blob/254f57ca3668398a5fcfd4f63be5d91c4c3b1cd4/actioncable/lib/action_cable/connection/stream_event_loop.rb#L66
>> >>
>> >> If a Ruby programmer sees a while true there instead, generally 
>> speaking
>> >> they would shake their heads a little bit. Why is this not a loop? A 
>> comment
>> >> would be needed: "This while true is here for performance".
>> >>
>> >> When is it OK to do a little strange thing for performance? Where it
>> >> matters, not systematically across the code base. So, for example, if 
>> you
>> >> change loop with while true in the previous example, probably there 
>> won't be
>> >> any noticeable difference. So you just don't.
>> >>
>> >> And if the gain is tiny, the cost of writing something less idiomatic,
>> >> elegant, or readable is still not worth it. Because code has to be 
>> read.
>> >>
>> >> You depart from this with a scalpel, precisely where it pays off.
>> >>
>> > --
>> > You received this message because you are subscribed to the Google 
>> Groups
>> > "Ruby on Rails: Core" group.
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an
>> > email to rubyonrails-core+unsubscr...@googlegroups.com.
>> > To post to this group, send email to rubyonrails-core@googlegroups.com.
>> > Visit this group at https://groups.google.com/group/rubyonrails-core.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at https://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Sent from Gmail Mobile
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Increase speed creating new array

[Andrey Molchanov]

Thanks for your feedback.
Yes, I will need find places where args passes to Array() is not kind of Array 
class.

пятница, 6 мая 2016 г., 1:02:26 UTC+3 пользователь Ufuk Kayserilioglu 
написал:
>
> Andrey,
>
> Be careful with this because the sematics of the two are not exactly equal:
>
> [1] pry(main)> Array([123])
> => [123]
> [2] pry(main)> [[123]]
> => [[123]]
>
>
> and the desired sematics in the locations that you link to seem to be the 
> Array() variant where the input might be a scalar or an array itself.
>
> --
> Ufuk Kayserilioglu
>
>
> On 6 May 2016 at 00:29:29, Andrey Molchanov (neo...@gmail.com 
> ) wrote:
> Hi all, 
> In some 
> <https://github.com/rails/rails/blob/master/activerecord/lib/active_record/associations/preloader/association.rb#L126>
>  places 
> <https://github.com/rails/rails/blob/master/activerecord/lib/active_record/associations/preloader/association.rb#L154>
>  new 
> array creates as a Array(). If we replace it to a [], we increase 
> performance about 1.7 times:
>
>
> def old_slow
>Array(123)
> end
>
> def new_fast
>[123]
> end
>
>
> Benchmark.ips do |x|
>   x.report("new_fast") { new_fast }
>   x.report("old_slow") { old_slow }
>   x.compare!
> end
>
> Calculating -
> new_fast   184.920k i/100ms
> old_slow   150.931k i/100ms
> -
> new_fast  7.528M (± 4.4%) i/s - 37.724M
> old_slow  4.408M (± 4.3%) i/s - 22.036M
>
> Comparison:
> new_fast:  7528299.2 i/s
> old_slow:  4408283.1 i/s - 1.71x slower
>
>
> What do you think about it?
> --
> You received this message because you are subscribed to the Google Groups 
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to rubyonrails-co...@googlegroups.com .
> To post to this group, send email to rubyonra...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

Re: [Rails-core] Increase performance

[Andrey Molchanov]

Thanks for your feedback.
I agree with you about use idioms for better readable code. Its cool, but 
Rails has many places where this not use. A lot of code can be corrected 
according to this, but this is not done.
And I thought, why not use it in favor of speed?
That is what I was based when wrote this message.


пятница, 6 мая 2016 г., 14:31:40 UTC+3 пользователь Xavier Noria написал:
>
> In general, the Rails code base wants to use Ruby idiomatically.
>
> loop is the most succinct idiom in Ruby for those kinds of loops, see for 
> example:
>
> https://github
> .com/rails/rails/blob/254f57ca3668398a5fcfd4f63be5d91c4c3b1cd4/actioncable
> /lib/action_cable/connection/stream_event_loop.rb#L66
>
> If a Ruby programmer sees a while true there instead, generally speaking 
> they would shake their heads a little bit. Why is this not a loop? A 
> comment would be needed: "This while true is here for performance".
>
> When is it OK to do a little strange thing for performance? Where it 
> matters, not systematically across the code base. So, for example, if you 
> change loop with while true in the previous example, probably there won't 
> be any noticeable difference. So you just don't.
>
> And if the gain is tiny, the cost of writing something less idiomatic, 
> elegant, or readable is still not worth it. Because code has to be read.
>
> You depart from this with a scalpel, precisely where it pays off.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Increase speed creating new array

[Andrey Molchanov]

Hi all,
In some 

 places 

 new 
array creates as a Array(). If we replace it to a [], we increase 
performance about 1.7 times:


def old_slow
   Array(123)
end

def new_fast
   [123]
end


Benchmark.ips do |x|
  x.report("new_fast") { new_fast }
  x.report("old_slow") { old_slow }
  x.compare!
end

Calculating -
new_fast   184.920k i/100ms
old_slow   150.931k i/100ms
-
new_fast  7.528M (± 4.4%) i/s - 37.724M
old_slow  4.408M (± 4.3%) i/s - 22.036M

Comparison:
new_fast:  7528299.2 i/s
old_slow:  4408283.1 i/s - 1.71x slower


What do you think about it?

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] Increase performance

[Andrey Molchanov]

I propose replace all the endless loop do to while true:

NUMBER = 100_000_000

def old_slow
  index = 0
  loop do
break if index > NUMBER
index += 1
  end
end

def new_fast
  index = 0
  while true
break if index > NUMBER
index += 1
  end
end


Benchmark.ips do |x|
  x.report("new_fast") { new_fast }
  x.report("old_slow") { old_slow }
  x.compare!
end

Calculating -
new_fast 1.000  i/100ms
old_slow 1.000  i/100ms
-
new_fast  0.655  (± 0.0%) i/s -  4.000  in   6.106470s
old_slow  0.259  (± 0.0%) i/s -  2.000  in   7.707258s

Comparison:
new_fast:0.7 i/s
old_slow:0.3 i/s - 2.52x slower


What do you think about it?

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.