[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70240] Re: [Ruby trunk - Feature #11375] Decreased Object Allocation in Pathname.rb
From:
Eric Wong <normalperson@...>
Date:
2015-08-04 08:22:46 UTC
List:
ruby-core #70240
richard.schneeman@gmail.com wrote:
> I think I figured out why i'm not getting emails and I believe I've
> fixed the issue. Sorry again for the delayed response.
No worries, I barely have Internet access the past few weeks.
I'm only subscribed to ruby-core, though.
<snip>
I understand your pain, and I've had to do optimizations like these
to fix known regressions such as https://bugs.ruby-lang.org/issues/10628
I hated making that commit, but in the end it's likely to affect
someone, so I made the changes anyways :<
Based on my comments on [ruby-core:70234], I would like you to
reevaluate the freeze changes on the case/when statements with:
a) multiple 'when' statements
b) non-matching 'when' statements
I'm alright if we uglify our code a little for consistent performance
gains, but not to introduce performance regressions :)
So I'm more likely to apply the patch with the case/when stuff sorted
out.
And I think there is at least one place where two `== x.freeze' checks
could be converted into a case/when without introducing the ugly
`freeze' word :)
> If we're talking optimizations, I would love for these two expressions
> to be roughly equivalent:
> require 'benchmark/ips'
>
> world = "world"
> Benchmark.ips do |x|
> x.report("normal") { "hello #{world}" }
> x.report("freeze") { "hello ".freeze + world }
> end
The normal way (concatstrings VM instruction) should already be faster
if there's a slightly more complex concatenation. It's not allocation
costs, just costs of instructions in this case.
For example, add a trailing space at the end to see what you get:
x.report("normal") { "hello #{world} " }
x.report("freeze") { "hello ".freeze + world << " " } # gross!
I'll see if I can make your original case faster, but it's already close
between them and it would be hard without introducing regressions
elsewhere.
It would be great if we could implement the putstring VM instruction
lazily, but I wonder how many C exts that would break...