[#73707] [Ruby trunk Misc#12004] Code of Conduct — hanmac@...
Issue #12004 has been updated by Hans Mackowiak.
3 messages
2016/02/05
[#73730] [Ruby trunk Feature#12034] RegExp does not respect file encoding directive — nobu@...
Issue #12034 has been updated by Nobuyoshi Nakada.
3 messages
2016/02/07
[#73746] [Ruby trunk Feature#12034] RegExp does not respect file encoding directive — nobu@...
Issue #12034 has been updated by Nobuyoshi Nakada.
3 messages
2016/02/09
[#73919] [Ruby trunk Feature#11262] Make more objects behave like "Functions" — Ruby-Lang@...
SXNzdWUgIzExMjYyIGhhcyBiZWVuIHVwZGF0ZWQgYnkgSsO2cmcgVyBNaXR0YWcuCgpQcm9qZWN0
3 messages
2016/02/22
[#74019] [Ruby trunk Bug#12103][Rejected] ruby process hangs while executing regular expression. — duerst@...
SXNzdWUgIzEyMTAzIGhhcyBiZWVuIHVwZGF0ZWQgYnkgTWFydGluIETDvHJzdC4KClN0YXR1cyBj
3 messages
2016/02/27
[ruby-core:73620] Re: [Ruby trunk - Feature #12024] Add String.buffer, for creating strings with large capacities
From:
Martin J. Dürst <duerst@...>
Date:
2016-02-01 01:44:32 UTC
List:
ruby-core #73620
On 2016/01/30 21:17, mame@ruby-lang.org wrote: > I have no strong objection, but still I have a question. I guess that creating a large string by concatenating many short strings is natural use case in Ruby. However, are there so much cases where we can predict the final length of a generated string before starting creating it? Usually, when doing something like result = "" loop do result << some_string end result this starts to get slow quite quickly. The standard advice (which I have myself used often) is to convert this to: result = [] loop do result << some_string end result.join This often speeds up things considerably. I haven't completely analyzed the code for Array#join, but on first impression, it seems to do exactly what you suggest: calculate the overall length first, then do the actual copying. Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>