[#19731] use of require thread safety — "Roger Pack" <rogerpack2005@...>

I'm sure this has been discussed before, but...should there be

56 messages 2008/11/08
[#19796] Re: use of require thread safety — Nobuyoshi Nakada <nobu@...> 2008/11/11

Hi,

[#21651] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2009/01/29

Nobuyoshi Nakada wrote:

[#19798] Re: use of require thread safety — "Roger Pack" <rogerpack2005@...> 2008/11/11

> While a thread is requiring a given file, another thread which

[#20732] Re: use of require thread safety — "Roger Pack" <rogerpack2005@...> 2008/12/20

> Currently with 1.8.7 (for me) the secondmost thread continues

[#20737] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/12/20

Roger Pack wrote:

[#20769] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/12/21

Charles Oliver Nutter wrote:

[#20795] Re: use of require thread safety — Paul Brannan <pbrannan@...> 2008/12/22

On Mon, Dec 22, 2008 at 03:05:07AM +0900, Charles Oliver Nutter wrote:

[#19821] Re: use of require thread safety — Paul Brannan <pbrannan@...> 2008/11/11

On Tue, Nov 11, 2008 at 10:51:45AM +0900, Nobuyoshi Nakada wrote:

[#19829] Re: use of require thread safety — Charles Oliver Nutter <charles.nutter@...> 2008/11/11

Paul Brannan wrote:

[#19759] Proposal: Method#get_args — "Yehuda Katz" <wycats@...>

I'd like to propose a way to introspect into the arguments of a method

97 messages 2008/11/09
[#19787] Re: Proposal: Method#get_args — "Roger Pack" <rogerpack2005@...> 2008/11/11

The only question I have is why would one want to know the names of

[#19789] Re: Proposal: Method#get_args — Trans <transfire@...> 2008/11/11

On Nov 10, 7:18=A0pm, "Roger Pack" <rogerpack2...@gmail.com> wrote:

[#19818] Re: Proposal: Method#get_args — Mikael Hlund <mikael@...> 2008/11/11

Allow me to throw in my ~.116892074 DKK;

[#19837] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/11

Mikael H淡ilund wrote:

[#19838] Re: Proposal: Method#get_args — Dave Thomas <dave@...> 2008/11/11

[#19870] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/12

On Wed, Nov 12, 2008 at 04:48:03AM +0900, Dave Thomas wrote:

[#19874] Re: Proposal: Method#get_args — Paul Brannan <pbrannan@...> 2008/11/12

On Wed, Nov 12, 2008 at 06:01:40PM +0900, Brian Candler wrote:

[#19881] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Paul Brannan wrote:

[#19887] Re: Proposal: Method#get_args — Paul Brannan <pbrannan@...> 2008/11/12

On Thu, Nov 13, 2008 at 02:06:15AM +0900, Charles Oliver Nutter wrote:

[#19889] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Paul Brannan wrote:

[#19892] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

[#19893] Re: Proposal: Method#get_args — Jim Deville <jdeville@...> 2008/11/12

> -----Original Message-----

[#19894] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/12

On Thu, Nov 13, 2008 at 04:33:07AM +0900, Jim Deville wrote:

[#19895] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

[#19896] Re: Proposal: Method#get_args — Charles Oliver Nutter <charles.nutter@...> 2008/11/12

Jim Weirich wrote:

[#19899] Re: Proposal: Method#get_args — Jim Weirich <jim.weirich@...> 2008/11/12

On Nov 12, 2008, at 4:12 PM, Charles Oliver Nutter wrote:

[#19915] Re: Proposal: Method#get_args — Brian Candler <B.Candler@...> 2008/11/13

On Thu, Nov 13, 2008 at 07:02:25AM +0900, Jim Weirich wrote:

[#19927] Re: {Proc,Method}#parameters (Re: Proposal: Method#get_args) — Nobuyoshi Nakada <nobu@...> 2008/11/14

Hi,

[#19784] Status of copy-on-write friendly garbage collector — Hongli Lai <hongli@...99.net>

Hi.

22 messages 2008/11/10
[#19799] Re: Status of copy-on-write friendly garbage collector — "Narihiro Nakamura" <authornari@...> 2008/11/11

Hi.

[#19812] Re: Status of copy-on-write friendly garbage collector — "Yehuda Katz" <wycats@...> 2008/11/11

Narihiro,

[#19823] Re: Status of copy-on-write friendly garbage collector — Yukihiro Matsumoto <matz@...> 2008/11/11

Hi,

[#19845] [Bug #743] Socket.gethostbyname returns odd values — Roger Pack <redmine@...>

Bug #743: Socket.gethostbyname returns odd values

11 messages 2008/11/11

[#19846] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...>

Bug #744: memory leak in callcc?

142 messages 2008/11/11
[#21394] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...> 2009/01/17

Issue #744 has been updated by Roger Pack.

[#21429] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/19

[#21441] Re: [Bug #744] memory leak in callcc? — Nobuyoshi Nakada <nobu@...> 2009/01/19

Hi,

[#21483] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/21

[#21487] Re: [Bug #744] memory leak in callcc? — Michal Babej <calcifer@...> 2009/01/21

On Wednesday 21 of January 2009 10:21:19 Brent Roman wrote:

[#21711] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/02/01

[#22062] Re: [Bug #744] memory leak in callcc? — Roger Pack <rogerdpack@...> 2009/02/14

>> I've tried that myself but it didn't work very well

[#22265] Re: [Bug #744] memory leak in callcc? — Michal Babej <calcifer@...> 2009/02/19

On Saturday 14 of February 2009 08:17:22 Roger Pack wrote:

[#21514] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2009/01/22

[#19945] [Bug #744] memory leak in callcc? — Roger Pack <redmine@...> 2008/11/15

Issue #744 has been updated by Roger Pack.

[#19968] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2008/11/17

[#19969] Re: [Bug #744] memory leak in callcc? — Martin Duerst <duerst@...> 2008/11/17

At 12:54 08/11/17, Brent Roman wrote:

[#19970] Re: [Bug #744] memory leak in callcc? — Brent Roman <brent@...> 2008/11/17

[#19972] Re: [Bug #744] memory leak in callcc? — Kurt Stephens <kurt@...> 2008/11/17

A common technique is to allocate a reasonably sized array (256-bytes)

[#20149] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/11/28

[#20517] Re: Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/13

> I implemented a scheme for recording the maximum depth of the C stack in

[#20534] Re: Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/13

[#20750] [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/21

[#20751] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Ezra Zygmuntowicz <ezmobius@...> 2008/12/21

[#20752] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/21

[#20781] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/22

First thanks for doing all that hard work. I'm sure it's not pleasant

[#20783] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/22

[#20903] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/26

Seems to overall be a tidge slower for "micro" stuff--5 or 10%.

[#20914] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/27

[#20922] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/27

> You ran this benchmark suite, correct?

[#20931] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/12/28

[#20995] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Roger Pack" <rogerpack2005@...> 2008/12/30

Hmm interesting.

[#21261] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use — "Stephen Sykes" <sdsykes@...> 2009/01/11

Brent,

[#20168] Re: Promising C coding techniques to reduce MRI's memory use — Nobuyoshi Nakada <nobu@...> 2008/11/30

Hi,

[#20175] Re: Promising C coding techniques to reduce MRI's memory use — Brian Candler <B.Candler@...> 2008/11/30

The problem can be demonstrated with a very simple program (attached), and

[#20178] Re: Promising C coding techniques to reduce MRI's memory use — Brent Roman <brent@...> 2008/11/30

[#20185] Re: Promising C coding techniques to reduce MRI's memory use — Brian Candler <B.Candler@...> 2008/12/01

> What I did come up with was not ugly at all. Factor the unwieldy switch

[#19938] Fibers in 1.8 — "Aman Gupta" <rubytalk@...1.net>

Are there any plans to backport Fiber to ruby 1.8?

13 messages 2008/11/15

[#20008] [Bug #766] 'Not enough space' error on windows — Ittay Dror <redmine@...>

Bug #766: 'Not enough space' error on windows

17 messages 2008/11/20

[#20092] [Bug #797] bug or feature: local method ? — Francois Proulx <redmine@...>

Bug #797: bug or feature: local method ?

23 messages 2008/11/25
[#20097] Re: [Bug #797] bug or feature: local method ? — Yukihiro Matsumoto <matz@...> 2008/11/25

Hi,

[#20098] Re: [Bug #797] bug or feature: local method ? — Dave Thomas <dave@...> 2008/11/25

[#20100] Re: [Bug #797] bug or feature: local method ? — Yukihiro Matsumoto <matz@...> 2008/11/25

Hi,

[#20127] Re: [Bug #797] bug or feature: local method ? — Francoys <francois.pr@...> 2008/11/26

Yukihiro Matsumoto wrote:

[ruby-core:20074] Re: Unexpected Performance of Symbol Construction

From: Ken Bloom <kbloom@...>
Date: 2008-11-24 15:33:49 UTC
List: ruby-core #20074
On Mon, 24 Nov 2008 14:39:45 +0900, Ryan Davis wrote:

> On Nov 23, 2008, at 01:11 , Kurt Stephens wrote:
> 
>> http://kurtstephens.com/node/72
>>
>> Evaluating :‘foo_bar’ is 1.5 to 2.5 times faster than :foo_bar. This is
>> true for both Ruby 1.8.6-p287 and Ruby 1.9 trunk.  The most common
>> means
>> of specifying a Symbol literal is slower than the general expression to
>> create a Symbol from a String constant.
> 
> for at least 1.8 (and I highly suspect 1.9 tho I'm not checking), there
> is literally no difference between :blah, :'blah', and :"blah" to the
> parser and therefor the eval loop. You can see that via parse_tree:
> 
>> % parse_tree_show -u
>> a = :blah, :'blah', :"blah"
>> s(:lasgn,
>>  :a,
>>  s(:svalue, s(:array, s(:lit, :blah), s(:lit, :blah),
>> s(:lit, :blah))))
> 
> Likewise, your case with interpolation:
> 
>> % parse_tree_show -u
>> :"foo_#{'bar'}"
>> s(:lit, :foo_bar)
> 
> You could assign a local variable with 'bar' and do that instead for a
> more fair comparison:
> 
>> % parse_tree_show -u
>> bar = "bar"
>> :"foo_#{bar}"
>> s(:block,
>>  s(:lasgn, :bar, s(:str, "bar")),
>>  s(:dsym, "foo_", s(:evstr, s(:lvar, :bar))))
> 
> Finally, you NEED to add a null benchmark to your measurements. When
> your benchmarks are coming that close to the null benchmark, you have to
> suspect that your experiment is flawed or your sample size is too small.
> I'm getting measurements at 1m samples that are only 50% more than null.
> And as I increase the samples, the number converges DOWN towards null.
> At 5m it is only 40% more.

Frankly I'm surprised that the simpler tests aren't intentionally equal 
to the null benchmark. The parser should be able to handle the simple 
cases for you so that all the work is done once, before you execute the 
first line of code. (And this is the behavior I see on ruby 1.9)

>> # of iterations = 5000000
>>                                user     system      total        real
>> null_time                  0.810000   0.010000   0.820000 (  0.843928)
>> :foo_bar                   1.140000   0.010000   1.150000 (  1.167343)
>> :'foo_bar'                 1.170000   0.020000   1.190000 (  1.256334)
>> :"foo_bar"                 1.110000   0.010000   1.120000 (  1.191425)
>> :"foo_#{'bar'}"            1.130000   0.010000   1.140000 (  1.164772)
>> "foo_#{'bar'}".to_sym      2.450000   0.200000   2.650000 (  2.702624)
>> "foo_bar".to_sym           2.530000   0.180000   2.710000 (  2.770743)
>> :"foo_#{bar}"              4.300000   0.430000   4.730000 (  7.484217)
>> "foo_#{bar}".to_sym        5.040000   0.170000   5.210000 (  5.493593)
> 
> What this is really saying to me, barring the GC issue you found, is
> that the numbers for plain symbols don't really matter at all. They're
> about as low as they're gonna get.
> 
> I do find it interesting that :"foo_#{bar}" is currently 40% slower than
> "foo_#{bar}".to_sym... I suspect there might be a minor issue there. But
> for the rest? *shrug* seems acceptable to me.

I'm not seeing this on 1.8 or 1.9. It must be the GC kicking in on your 
system, in the middle of this benchmark, because that benchmark happens 
to be the straw that broke the camel's back. In which case, GC isn't an 
issue either -- just a totally appropriate behavior that happens to be 
kicking in at just the wrong time. To deal with this, either run the 
tests in a random order and average over several runs or run GC.start 
before each benchmark.

Here's my Ruby 1.9 tests, run for 10_000_000 iterations, seem to support 
the reasonable conclusions various people have mentioned.

                           user     system      total        real
null                   1.460000   0.000000   1.460000 (  1.644902)
:foo_bar               1.480000   0.000000   1.480000 (  1.654968)
:'foo_bar'             1.440000   0.000000   1.440000 (  1.594285)
:"foo_bar"             1.450000   0.000000   1.450000 (  1.651050)
"foo_bar".to_sym       8.640000   0.060000   8.700000 (  9.806916)
:"foo_#{'bar'}"        1.440000   0.000000   1.440000 (  1.586956)
"foo_#{'bar'}".to_sym  8.810000   0.050000   8.860000 ( 10.161624)
:"foo_#{bar}"         14.080000   0.040000  14.120000 ( 16.065701)
"foo_#{bar}".to_sym   13.980000   0.040000  14.020000 ( 15.937608)

On Ruby 1.8, the null loop is faster than one that refers to a symbol 
constant, and I don't know why. Is the parser not doing the work, or is 
it just time taken to visit an additional AST node and return a return 
value?

                           user     system      total        real
null                   1.770000   0.000000   1.770000 (  1.858659)
:foo_bar               4.240000   0.900000   5.140000 (  5.501225)
:'foo_bar'             4.260000   0.880000   5.140000 (  5.498005)
:"foo_bar"             4.320000   0.790000   5.110000 (  5.425099)
"foo_bar".to_sym      11.150000   0.970000  12.120000 ( 13.336549)
:"foo_#{'bar'}"        4.300000   0.830000   5.130000 (  5.541806)
"foo_#{'bar'}".to_sym 11.120000   1.030000  12.150000 ( 13.236672)
:"foo_#{bar}"         15.180000   1.060000  16.240000 ( 18.203953)
"foo_#{bar}".to_sym   17.560000   0.990000  18.550000 ( 20.952985)


(Hot tip: the number that you pass to Benchmark.bm isn't the number of 
tests, it's the width of the labels. There's no need for the "\t\t" stuff 
that you had in the tests.)

require 'benchmark'

n = 10_000_000

Benchmark.bm('"foo_#{\'bar\'}".to_sym'.size) { | x |
  GC.start
  x.report("null") do
    n.times do
    end
  end
  
  GC.start

  x.report(':foo_bar') {
    n.times { 
      :foo_bar
    }
  }
  GC.start
  x.report(":'foo_bar'") {
    n.times { 
      :'foo_bar'
    }
  }
  GC.start
  x.report(':"foo_bar"') {
    n.times { 
      :"foo_bar"
    }
  }
  GC.start
  x.report('"foo_bar".to_sym') {
    n.times { 
      "foo_bar".to_sym
    }
  }
  GC.start
  x.report(':"foo_#{\'bar\'}"') { 
    n.times { 
      :"foo_#{'bar'}"
    }
  }
  GC.start
  x.report('"foo_#{\'bar\'}".to_sym') {
    n.times {
      "foo_#{'bar'}".to_sym
    }
  }
  GC.start
  x.report(':"foo_#{bar}"') do
    bar="bar"
    n.times do
      :"foo_#{bar}"
    end
  end
  GC.start
  x.report('"foo_#{bar}".to_sym') do
    bar="bar"
    n.times do
      "foo_#{bar}".to_sym
    end
  end
}


-- 
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/


In This Thread