I was playing around with the SyncEnumerator from Ruby 1.8, and
noticed that it was taking a long time to iterate over elements.
The current implementation may be the "correct", or elegant, way to
implement it, but it is terribly inefficient. I rewrote the class,
and got the following results:
Construction
Old: 0.159291
New: 0.000352
Starting SyncEnumerator
................................................................................
26 shold be 26 :: Time: 19.686455
Starting SyncEnumerator_
................................................................................
26 shold be 26 :: Time: 0.028817
The new version is nearly three orders of magnitude faster for
construction, and is three orders of magnitude faster in execution.
Is there any reason why I shouldn't submit this as an RCR to replace
SyncEnumerator?
I wonder how an implementation using .zip with a block would compare? Or would that not do the same thing?
> I was playing around with the SyncEnumerator from Ruby 1.8, and
> noticed that it was taking a long time to iterate over elements.
>
> The current implementation may be the "correct", or elegant, way to
> implement it, but it is terribly inefficient. I rewrote the class,
> and got the following results:
>
> Construction
> Old: 0.159291
> New: 0.000352
> Starting SyncEnumerator
> ................................................................................
> 26 shold be 26 :: Time: 19.686455
> Starting SyncEnumerator_
> ................................................................................
> 26 shold be 26 :: Time: 0.028817
>
> The new version is nearly three orders of magnitude faster for
> construction, and is three orders of magnitude faster in execution.
>
> Is there any reason why I shouldn't submit this as an RCR to replace
> SyncEnumerator?
I wonder how an implementation using .zip with a block would compare? Or
would that not do the same thing?
Hmm... I don't have the OP's message in my archives...
Assuming it's a transparent change, improving performance without
breaking code, why not just submit it to ruby-core? People are always
posting bug patches there, I suspect that a performance patch wouldn't
be unwelcome.
cheers,
Mark
···
On Thu, 4 Nov 2004 21:28:45 +0900, Florian Gross <flgr@ccan.de> wrote:
That'll send an email of the patch summary and description to ruby-core
as well. Also, then you can post updated version of the patch as you
get feedback, and other folks will be able to monitor the patch and get
notified of the updates.
Yours,
tom
···
On Fri, 2004-11-05 at 16:27, Mark Hubbart wrote:
Assuming it's a transparent change, improving performance without
breaking code, why not just submit it to ruby-core? People are always
posting bug patches there, I suspect that a performance patch wouldn't
be unwelcome.
I've been a member of the Ruby community for I don't know how long now, and I
*still* haven't figured out when a patch should be submitted to ruby-core,
and when to RCR. :-/
···
On Friday 05 November 2004 16:32, Tom Copeland wrote:
On Fri, 2004-11-05 at 16:27, Mark Hubbart wrote:
> Assuming it's a transparent change, improving performance without
> breaking code, why not just submit it to ruby-core? People are always
> posting bug patches there, I suspect that a performance patch wouldn't
> be unwelcome.
That'll send an email of the patch summary and description to ruby-core
as well. Also, then you can post updated version of the patch as you
get feedback, and other folks will be able to monitor the patch and get
notified of the updates.
In message "Re: SyncEnumerator" on Sun, 7 Nov 2004 11:52:59 +0900, "Sean E. Russell" <ggg@ser1.net> writes:
I've been a member of the Ruby community for I don't know how long now, and I
*still* haven't figured out when a patch should be submitted to ruby-core,
and when to RCR. :-/
If you think the change is to fix the bug (i.e. difference from the
behavior you assume I (matz) expect), send it to the ruby-core list.
If the change is to make Ruby better in your point of view, submit
RCR, then raise the discussion on the list.
In message "Re: SyncEnumerator" > on Sun, 7 Nov 2004 11:52:59 +0900, "Sean E. Russell" <ggg@ser1.net> writes:
>I've been a member of the Ruby community for I don't know how long now, and I
>*still* haven't figured out when a patch should be submitted to ruby-core,
>and when to RCR. :-/
If you think the change is to fix the bug (i.e. difference from the
behavior you assume I (matz) expect), send it to the ruby-core list.
If the change is to make Ruby better in your point of view, submit
RCR, then raise the discussion on the list.
I've been a member of the Ruby community for four years (minus roughly
13 hours; my first post to ruby-talk was November 7, 2000, at 21:52
EST and one thing I'm not sure of is.....
To what extent should RCR discussion be here, and to what extent
should it be on the message/comment space on RCRchive?
If you think the change is to fix the bug (i.e. difference from the
behavior you assume I (matz) expect), send it to the ruby-core list.
If the change is to make Ruby better in your point of view, submit
RCR, then raise the discussion on the list.
matz.
but /just/ making something faster seems a ruby-core thing, cause it is better in everyone's point of view (well, except for making sleep() faster)
To what extent should RCR discussion be here, and to what extent
should it be on the message/comment space on RCRchive?
I prefer discussion on the list, especially for more something than
simple discussion.
* wider range of opinion can be gathered.
* I prefer push model of mail lists to web's pull model.
* summaries are often better organized on the web discussion,
though.
matz.
···
In message "Re: RCR discussions (was: Re: SyncEnumerator)" on Sun, 7 Nov 2004 23:08:28 +0900, "David A. Black" <dblack@wobblini.net> writes:
I've been a member of the Ruby community for four years (minus roughly
13 hours; my first post to ruby-talk was November 7, 2000, at 21:52
EST
Wow, how time flies!
and one thing I'm not sure of is.....
To what extent should RCR discussion be here, and to what extent
should it be on the message/comment space on RCRchive?
If you have a glimmer of an RCR, and have done your research (at least googled
the topic on the mail list), the the mailing list is a good place to solicite
feedback. Hopefully the research step will get you beyond the topics that
have been hashed out over and over (and over and over and ... well, you get
the idea).
On Sunday 07 November 2004 09:08 am, David A. Black wrote:
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
> I've been a member of the Ruby community for four years (minus roughly
> 13 hours; my first post to ruby-talk was November 7, 2000, at 21:52
> EST
Wow, how time flies!
> and one thing I'm not sure of is.....
>
> To what extent should RCR discussion be here, and to what extent
> should it be on the message/comment space on RCRchive?
If you have a glimmer of an RCR, and have done your research (at least googled
the topic on the mail list), the the mailing list is a good place to solicite
feedback. Hopefully the research step will get you beyond the topics that
have been hashed out over and over (and over and over and ... well, you get
the idea).
I would also emphasize the importance of reading the rejected RCRs on
RCRchive, along with the list archives.
I've read it -- actually it's been linked in to RCRchive as required
reading from the beginning
It just seems there are different scenarios in practice: submitting at
RCRchive first, then discussing here (which the scenario Matz was
endorsing this morning), discussing first and then submitting (which
happens a lot, even unendorsed :-), submitting and using the comment
space on RCRchive, etc. I guess it's partly that discussion in any
forum sometimes happens to move toward discussion of possible language
changes, so in that sense pre-RCR discussion happens spontaneously.
(And it may not matter too much, as long as the basic tenets of
non-rehashing and non-resubmission of rejected ideas are followed.)
David
···
On Mon, 8 Nov 2004, Jim Weirich wrote:
On Sunday 07 November 2004 09:08 am, David A. Black wrote:
and one thing I'm not sure of is.....