[#75687] [Ruby trunk Bug#12416] struct rb_id_table lacks mark function — shyouhei@...
Issue #12416 has been reported by Shyouhei Urabe.
3 messages
2016/05/23
[#75763] [Ruby trunk Feature#12435] Using connect_nonblock to open TCP connections in Net::HTTP#connect — mohamed.m.m.hafez@...
Issue #12435 has been reported by Mohamed Hafez.
3 messages
2016/05/28
[#75774] Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock — Mohamed Hafez <mohamed.m.m.hafez@...>
Hi all, every now and then in my production server, I'm
4 messages
2016/05/30
[#75775] Re: Errno::EAGAIN thrown by OpenSSL::SSL::SSLSocket#connect_nonblock
— Mohamed Hafez <mohamed.m.m.hafez@...>
2016/05/30
Or does MRI's OpenSSL::SSL::SSLSocket#connect_nonblock just return
[#75782] Important: Somewhat backwards-incompatible change (Fwd: [ruby-cvs:62388] duerst:r55225 (trunk): * string.c: Activate full Unicode case mapping for UTF-8) — Martin J. Dürst <duerst@...>
With the change below, I have activated full Unicode case mapping for
4 messages
2016/05/31
[ruby-core:75738] [Ruby trunk Feature#11098] Thread-level allocation counting
From:
ko1@...
Date:
2016-05-27 09:12:25 UTC
List:
ruby-core #75738
Issue #11098 has been updated by Koichi Sasada.
Thank you for your explanation.
After that we need to measure the gem version of this feature.
Can you write it? or should I write?
----------------------------------------
Feature #11098: Thread-level allocation counting
https://bugs.ruby-lang.org/issues/11098#change-58866
* Author: Jason Clark
* Status: Feedback
* Priority: Normal
* Assignee:
----------------------------------------
This patch introduces a thread-local allocation count. Today you can get a
global allocation count from `GC.stat`, but in multi-threaded contexts that
can give a muddied picture of the allocation behavior of a particular piece of
code.
Usage looks like this:
```
[2] pry(main)> Thread.new do
[2] pry(main)* 1000.times do
[2] pry(main)* Object.new
[2] pry(main)* end
[2] pry(main)* puts Thread.current.allocated_objects
[2] pry(main)* end
1000
```
This would be of great interest to folks profiling Ruby code in cases where we
can't turn on more detailed object tracing tools. We currently use GC activity
as a proxy for object allocations, but this would let us be way more precise.
Obviously performance is a big concern. Looking at GET_THREAD, this doesn't
appear to have any clearly large overhead. To check this out, I ran the
following benchmark:
```
require 'benchmark/ips'
Benchmark.ips do |benchmark|
benchmark.report "Object.new" do
Object.new
end
benchmark.report "Object.new" do
Object.new
end
benchmark.report "Object.new" do
Object.new
end
end
```
Results from a few run-throughs locally:
Commit 9955bb0 on trunk:
```
Calculating -------------------------------------
Object.new 105.244k i/100ms
Object.new 105.814k i/100ms
Object.new 106.579k i/100ms
-------------------------------------------------
Object.new 4.886M (賊 4.5%) i/s - 24.417M
Object.new 4.900M (賊 1.9%) i/s - 24.549M
Object.new 4.835M (賊 7.4%) i/s - 23.980M
```
With this patch:
```
Calculating -------------------------------------
Object.new 114.248k i/100ms
Object.new 114.508k i/100ms
Object.new 114.472k i/100ms
-------------------------------------------------
Object.new 4.776M (賊 5.1%) i/s - 23.878M
Object.new 4.767M (賊 5.2%) i/s - 23.818M
Object.new 4.818M (賊 1.5%) i/s - 24.154M
```
I don't have a good sense of whether this is an acceptable level of change or
not, but I figured without writing the code to test there was no way
to know. What do you think?
---Files--------------------------------
thread-local.patch (2.04 KB)
thread-local-update.patch (2.05 KB)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>