[Rails-core] Increase speed creating new array

Hi all, In some places new array creates as a Array().

[Rails-core] Increase performance

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|

Re: [Rails-core] Increase performance

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

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

> > [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 Kay

Re: [Rails-core] Increase performance

` 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:4

Re: [Rails-core] Increase performance

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

Re: [Rails-core] Increase performance

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 напис

[Rails-core] Timestamps in migration

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

Re: [Rails-core] Timestamps in migration

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 <n

Re: [Rails-core] Timestamps in migration

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 написал: &

Re: [Rails-core] Timestamps in migration

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

[Rails-core] Question

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

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

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|