[#113107] [Ruby master Bug#19576] Backport request: Gemfile.lock resolving is broken with bundler shipped with Ruby 3.1.4 — "jprokop (Jarek Prokop) via ruby-core" <ruby-core@...>

Issue #19576 has been reported by jprokop (Jarek Prokop).

8 messages 2023/04/04

[#113112] [Ruby master Bug#19578] abort() shows stack trace when run within rescue clause — "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@...>

Issue #19578 has been reported by Dan0042 (Daniel DeLorme).

8 messages 2023/04/04

[#113180] [Ruby master Feature#19588] Allow Comparable#clamp(min, max) to accept nil as a specification — "kyanagi (Kouhei Yanagita) via ruby-core" <ruby-core@...>

Issue #19588 has been reported by kyanagi (Kouhei Yanagita).

7 messages 2023/04/11

[#113209] [Ruby master Bug#19596] Decreased performance after upgrading from ruby 2.7.2 to ruby 3.2.2 — silva96 via ruby-core <ruby-core@...>

Issue #19596 has been reported by silva96 (Benjam=EDn Silva).

7 messages 2023/04/13

[#113238] [Ruby master Misc#19599] DevMeeting-2023-05-10 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #19599 has been reported by mame (Yusuke Endoh).

14 messages 2023/04/14

[#113285] [Ruby master Bug#19607] Introduce `Hash#symbolize_keys`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>

Issue #19607 has been reported by ioquatix (Samuel Williams).

8 messages 2023/04/18

[#113303] [Ruby master Feature#19610] GC.delay_promotion — "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>

Issue #19610 has been reported by peterzhu2118 (Peter Zhu).

9 messages 2023/04/20

[#113313] [Ruby master Bug#19613] Add version information to all function documentation — "fulldecent (William Entriken) via ruby-core" <ruby-core@...>

Issue #19613 has been reported by fulldecent (William Entriken).

7 messages 2023/04/23

[#113342] [Ruby master Feature#19617] Add Method#binding and UnboundMethod#binding, similar to Proc#binding — "nevans (Nicholas Evans) via ruby-core" <ruby-core@...>

Issue #19617 has been reported by nevans (Nicholas Evans).

9 messages 2023/04/25

[#113381] [Ruby master Bug#19624] Backticks - IO object leakage — pineman via ruby-core <ruby-core@...>

Issue #19624 has been reported by pineman (Jo=E3o Pinheiro).

10 messages 2023/04/30

[ruby-core:113258] [Ruby master Bug#4040] SystemStackError with Hash[*a] for Large _a_

From: "jeremyevans0 (Jeremy Evans) via ruby-core" <ruby-core@...>
Date: 2023-04-14 16:23:57 UTC
List: ruby-core #113258
Issue #4040 has been updated by jeremyevans0 (Jeremy Evans).


I rebased my branch against master, and then ran all of the `app_*` benchmarks, here are the results:

```
app_aobench: +1%
app_erb: 0%
app_factorial: 0%
app_fib: +5%
app_lc_fizzbuzz: 0%
app_mandelbrot: 0%
app_pentomino: -1%
app_raise: 0%
app_strconcat: +8%
app_tak: +4%
app_tarai: +3%
app_uri: -2%
```

For most of the benchmarks, I ran with `--repeat-count 10 --repeat-result best` (some take a long time and I only ran with 1 or 3 instead of 10).

So from this benchmarking, only `app_pentomino` and `app_uri` are slower, by 1-2%.  5 benchmarks are faster, by up to 8%. 5 benchmarks did not show any performance differences.

`app_fib` is showing up 5% faster now, when it was previously showing 1-3% slower.  To make sure this wasn't an anomaly, I ran with `--repeat-count 25`, and still got the same results. Again, this could just be due to my environment (OpenBSD), as I cannot think of a reason why `app_fib` would be faster with the changes.

All of these benchmarks are more of the microbenchmark nature.  More realistic benchmarks such as yjit-bench on Linux would be better for testing actual differences in performance.

----------------------------------------
Bug #4040: SystemStackError with Hash[*a] for Large _a_
https://bugs.ruby-lang.org/issues/4040#change-102814

* Author: runpaint (Run Paint Run Run)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* ruby -v: ruby 1.9.3dev (2010-11-09 trunk 29737) [x86_64-linux] 
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
=begin
 I've been hesitating over whether to file a ticket about this, so please feel free to close if I've made the wrong choice.
 
 I often use Hash[*array.flatten] in IRB to convert arrays of arrays into hashes. Today I noticed that if the array is big enough, this would raise a SystemStackError. Puzzled, I looked deeper. I assumed I was hitting the maximum number of arguments a method's argc can hold, but realised that the minimum size of the array needed to trigger this exception differed depending on whether I used IRB or not. So, presumably this is indeed exhausting the stack...
 
 In IRB, the following is the minimal reproduction of this problem:
 
   Hash[*130648.times.map{ 1 }]; true
 
 I haven't looked for the minimum value needed with `ruby -e`, but the following reproduces:
 
   ruby -e 'Hash[*1380888.times.map{ 1 }]'
 
 I suppose this isn't technically a bug, but maybe it offers another argument for either #666 or an extension of #3131.
=end




-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread

Prev Next