[#62297] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap. — Eric Wong <normalperson@...>
[email protected] wrote:
7 messages
2014/05/02
[#62307] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— SASADA Koichi <ko1@...>
2014/05/03
(2014/05/03 4:41), Eric Wong wrote:
[#62402] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— Eric Wong <normalperson@...>
2014/05/05
SASADA Koichi <[email protected]> wrote:
[#62523] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — ko1@...
Issue #9632 has been updated by Koichi Sasada.
3 messages
2014/05/11
[#62556] doxygen (Re: Re: [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan) — Tanaka Akira <akr@...>
2014-05-11 8:50 GMT+09:00 Eric Wong <[email protected]>:
3 messages
2014/05/13
[#62727] [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl — Eric Wong <normalperson@...>
rb_unlink_method_entry may cause old_me to be swept before the new
7 messages
2014/05/24
[#63039] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/10
Hi,
[#63077] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/10
SASADA Koichi <[email protected]> wrote:
[#63086] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/11
(2014/06/11 4:47), Eric Wong wrote:
[#63087] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/11
SASADA Koichi <[email protected]> wrote:
[#62862] [RFC] README.EXT: document rb_gc_register_mark_object — Eric Wong <normalperson@...>
Any comment on officially supporting this as part of the C API?
5 messages
2014/05/30
[ruby-core:62704] [ruby-trunk - Feature #9508] Add method coverage and branch coverage metrics
From:
sam.rawlins@...
Date:
2014-05-22 02:29:23 UTC
List:
ruby-core #62704
Issue #9508 has been updated by Sam Rawlins.
Hi Yusuke, I looked into the performance issue:
* I used the mail gem specs as a slightly longer performance test. Without Coverage, the specs take 10.5 seconds. The current Coverage library increases that by 14%. My proposed changes instead increase by 57% (6 seconds total). Ouch!
* I used the jekyll gem specs as a much longer performance test. Without Coverage, the specs take 112 seconds. The current Coverage library increases that by 4%. My proposed changes instead increase by 11% (12 seconds total). Not too bad...
* results here: https://gist.github.com/srawlins/5b0fe367cd3a412e6925
Maybe this proposal (with Hashes) isn't too bad. However, I wrote a patch to my proposed changes (changing the :methods and :decisions values to be Arrays instead of Hashes), which decreases the slowdown by some, but not much (instead of increasing mail specs by 57%, this patch only increases them 38%; 4 seconds).
Another possible solution is to allow the user to specify what should be tracked, with something like
Coverage.start # track everything?
Coverage.start(:lines) # track lines
Coverage.start(:lines, :methods) # track lines and methods
This would be a large change, and I would prefer writing it in a different feature if we want to do it...
What do you think of all of this?
----------------------------------------
Feature #9508: Add method coverage and branch coverage metrics
https://bugs.ruby-lang.org/issues/9508#change-46827
* Author: Sam Rawlins
* Status: Assigned
* Priority: Normal
* Assignee: Yusuke Endoh
* Category: core
* Target version: current: 2.2.0
----------------------------------------
Since the Coverage extension was introduced in Ruby 1.9, Ruby has had built-in line code coverage. Ruby should support more of the basic code coverage metrics [1]. I have a pull request on GitHub ( https://github.com/ruby/ruby/pull/511 ) to add Method Coverage (Function Coverage) and Branch Coverage. I'd love feedback to improve it.
Currently, with this feature, Coverage.result would look like:
{"/Users/sam/code/ruby/cov_method.rb" => {
lines: [1, 2, 2, 20, nil, nil, 2, 2, 2, nil, 0, nil, nil, nil, 1, 0, nil, nil, 1, 1, nil, nil, 1],
methods: {1=>2, 15=>0, 19=>1},
branches: {8=>2, 11=>0}
}}
which includes
* the current Ruby line coverage report,
* as well as a method report (The method defined on line 1 was called 2 times; the method on line 15 was called 0 times; ...),
* and a branch report (the branch on line 8 was called 2 times; the branch on line 11 was called 0 times).
Branches
--------
Branches include the bodies of if, elsif, else, unless, and when statements, which are all tracked with this new feature. However, this feature is not aware of void bodies, for example:
if foo
:ok
end
will report that only one branch exists in the file. It would be better to declare that there is a branch body on line 2, and a void branch body on line 3, or perhaps line 1. This would require the keys of the [:branch] Hash to be something other than line numbers. Perhaps label_no? Perhaps nd_type(node) paired with line or label_no?
More Coverage
-------------
I think that Statement Coverage, and Condition Coverage could be added to this feature, using the same techniques.
Caveats
-------
I was not very clear on the bit-arrays used in ruby.h, and just used values for the new macros that seemed to work.
Also, I would much rather use Ranges to identify a branch, so that a Coverage analyzer like SimpleCov won't need any kind of Ruby parser to identify and highlight a full chunk of code as a tested branch, or a not tested branch. I'm trying to find how that could be implemented...
[1] Wikipedia has good definitions: http://en.wikipedia.org/wiki/Code_coverage
---Files--------------------------------
pull-request-511.patch (26.7 KB)
pull-request-511.patch (38.5 KB)
pull-request-511.patch (57 KB)
--
https://bugs.ruby-lang.org/