[#54738] [ruby-trunk - Bug #8358][Open] TestSprintf#test_float test failuer on mingw32 — "phasis68 (Heesob Park)" <phasis@...>

36 messages 2013/05/02

[#54749] [ruby-trunk - Feature #8361][Open] Alternative syntax for block parameter — "alexeymuranov (Alexey Muranov)" <redmine@...>

12 messages 2013/05/02

[#54798] [ruby-trunk - Bug #8370][Open] Constants MAX_MULTIPART_LENGTH in cgi\core.rb — "xibbar (Takeyuki FUJIOKA)" <xibbar@...>

17 messages 2013/05/05

[#54850] [ruby-trunk - Feature #8377][Open] Deprecate :: for method calls in 2.1 — "charliesome (Charlie Somerville)" <charliesome@...>

27 messages 2013/05/07

[#54881] [ruby-trunk - Bug #8384][Open] Cannot build ruby against OpenSSL build with "no-ec2m" — "vo.x (Vit Ondruch)" <v.ondruch@...>

16 messages 2013/05/09

[#54921] [ruby-trunk - Bug #8393][Open] A class who's parent class is in a module can go wrong if files are required in the wrong order — "eLobato (Daniel Lobato Garcia)" <elobatocs@...>

15 messages 2013/05/12

[#54939] [ruby-trunk - Bug #8399][Open] Remove usage of RARRAY_PTR in C extensions when not needed — "dbussink (Dirkjan Bussink)" <d.bussink@...>

32 messages 2013/05/12

[#55053] [ruby-trunk - Feature #8426][Open] Implement class hierarchy method caching — "charliesome (Charlie Somerville)" <charliesome@...>

21 messages 2013/05/19

[#55096] [ruby-trunk - Feature #8430][Open] Rational number literal — "mrkn (Kenta Murata)" <muraken@...>

28 messages 2013/05/21

[#55197] [ruby-trunk - Feature #8461][Open] Easy way to disable certificate checking in XMLRPC::Client — "herwinw (Herwin Weststrate)" <herwin@...>

11 messages 2013/05/29

[ruby-core:54904] Re: Plan to the first 2.0.0 patchlevel release.

From: Jon <jon.forums@...>
Date: 2013-05-10 17:05:02 UTC
List: ruby-core #54904
> 2013/5/6 Jon <jon.forums@gmail.com>:
> >> > #8142
> >> > #8143
> >> > #8149
> >> These seem like performance optimization patches.
> >> The optimization patches have less priority for backport.
> >> I think a patch achieves noticeable performance improvement could be treated
> >> as "a bug fix". It'll fixes a heavy performance reduction ;-)
> >> But now, just before the coming release, I want to be conservative.
> >
> > I don't understand your comment.
> >
> > Is your concern that the internal improvement patches are too complex to backport this close to the
> > coming release, but you plan to backport them for the next 2.0.0 patchlevel release?
> >
>
> On Sat, 11 May 2013 00:45:11 +0900
> Tomoyuki Chikanaga <nagachika00@gmail.com> wrote:
> No.
> Basically, optimization is not a subject of backport.
> If you think they are worth enough to backport, please move the
> tickets to Ruby200 project,
> or file a backport ticket with your reason.

I now understand the issue, thank you.

I have a different perspective on #8142, #8143, and #8149 and ask that you reconsider backporting
the patches to ruby_2_0_0 (not 1_9_x) for the following reasons:

1) While it is true that by removing unnecessary allocations and duplications these patches could be
viewed as optimizations, the patches could also be viewed as fixes to an "incorrect" original impl.
By "incorrect" I mean that Aman's code which performs fewer allocations and duplications is likely
what the original author would have preferred if he would have had more real-world usage info before
creating the original code. Yes, the old see-into-the-future gift ;)

2) The scope and size of the patches are small.

3) The patches do not appear to be the cause of new regressions on rubyci.org or ci.rubyinstaller.org.

4) Ruby 2.0.0 is the latest release and likely has not been accepted as the mainstream production-ready
version by a majority of users. Aman's patches make 2.0.0 more attractive, not less, and appear to have
minimal risk. Rather than incenting people to maintain private patch queues to gain the benefits of these
patches, the patches belong on the official ruby_2_0_0 branch.

As an aside (and regardless of what you decide) thank you for your spectacular efforts maintaining 2.0.0. In
my time with MRI I can't remember a time of such timely and regular backporting. Fabulous! :)

Jon

In This Thread

Prev Next