[#85349] [Ruby trunk Bug#14334] Segmentation fault after running rspec (ruby/2.5.0/erb.rb:885 / simplecov/source_file.rb:85) — pragtob@...
Issue #14334 has been updated by PragTob (Tobias Pfeiffer).
3 messages
2018/02/02
[#85358] Re: [ruby-cvs:69220] nobu:r62039 (trunk): compile.c: unnecessary freezing — Eric Wong <normalperson@...>
nobu@ruby-lang.org wrote:
5 messages
2018/02/03
[#85612] Why require autoconf 2.67+ — leam hall <leamhall@...>
Please pardon the intrusion; I am new to Ruby and like to pull the
6 messages
2018/02/17
[#85634] [Ruby trunk Bug#14494] [PATCH] tool/m4/ruby_replace_type.m4 use AC_CHECK_TYPES for HAVE_* macros — normalperson@...
Issue #14494 has been reported by normalperson (Eric Wong).
3 messages
2018/02/19
[#85674] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — matz@...
Issue #13618 has been updated by matz (Yukihiro Matsumoto).
5 messages
2018/02/20
[#85686] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Eric Wong <normalperson@...>
2018/02/20
matz@ruby-lang.org wrote:
[#85704] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid
— Koichi Sasada <ko1@...>
2018/02/21
On 2018/02/20 18:06, Eric Wong wrote:
[ruby-core:85666] Re: [Ruby trunk Feature#12589] VM performance improvement proposal
From:
Vladimir Makarov <vmakarov@...>
Date:
2018-02-20 04:40:50 UTC
List:
ruby-core #85666
On 02/19/2018 05:17 PM, sam.saffron@gmail.com wrote: > Issue #12589 has been updated by sam.saffron (Sam Saffron). > > > I just measured your branch using Discourse bench at: https://github.com/discourse/discourse/blob/master/script/bench.rb > > Looks like it is a bit slower than master: Trace insn are still generated on the branch. The current trunk does not generate them. Removing trace insns by Koichi improved performance by about 10%. I believe the branch will be faster when the trace insns are also removed there. But it is hard to predict what the actual improvement will be after that. > RTL: > > ``` > timings: > load_rails: 3749 > ruby-version: 2.5.0-p-1 > rss_kb: 247952 > pss_kb: 236618 > memorysize: 5.88 GB > virtual: vmware > architecture: amd64 > operatingsystem: Ubuntu > processor0: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz > physicalprocessorcount: 1 > kernelversion: 4.4.0 > > ``` > > Master > > ``` > timings: > load_rails: 3789 > ruby-version: 2.6.0-p-1 > rss_kb: 276588 > pss_kb: 265237 > memorysize: 5.88 GB > virtual: vmware > architecture: amd64 > operatingsystem: Ubuntu > processor0: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz > physicalprocessorcount: 1 > kernelversion: 4.4.0 > > ``` > > Very interesting to see the significant memory improvement, is that expected? No. Actually I expected more memory usage for RTL. It is hard for me to say a reason for memory improvement for now. When the current trunk will be merged into the branch, I could speculate more. Now the branch code is far behind (about 13 months) the current trunk. > only env var I am running is: `RUBY_GLOBAL_METHOD_CACHE_SIZE: 131072` > Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>