Skip to content
  • Jesse Sharps's avatar
    fbb37c0a
    railties/test_parser: Cache work done in definition_for. · fbb37c0a
    Jesse Sharps authored
    
    
    `definition_for` is used to extract the line numbers of a test, which
    is relevant when filtering tests to a line number or range, eg
    my_test.rb:1-2.
    
    The filter itself operates by, for each test, comparing the lines the
    test spans against the filter. In the current code, this will call
    `Prism.parse_file` and then walk the parse result until the matching
    definition/call is found.
    
    For files with a large number of tests, this is fairly onerous and can
    dominate the test runtime. Fortunately, we can parse the file once and
    cache the starts and ends of every def/call node.
    This beings the `definition_for` runtime down from seconds to low
    milliseconds.
    
    We also see a reduction in gc time that is probably attributable to
    not repeatedly parsing the file.
    For a test run in an 240 test file that went from 11s of parsing to
    20ms, gc went from 4.5-2.2 seconds.
    
    Finally, for any user that has written a reporter or otherwise hooked
    into the filters, this should provide speedup as well.
    
    Co-authored-by: default avatarStath Stivaros <stath.stivaros@shopify.com>
    fbb37c0a
    railties/test_parser: Cache work done in definition_for.
    Jesse Sharps authored
    
    
    `definition_for` is used to extract the line numbers of a test, which
    is relevant when filtering tests to a line number or range, eg
    my_test.rb:1-2.
    
    The filter itself operates by, for each test, comparing the lines the
    test spans against the filter. In the current code, this will call
    `Prism.parse_file` and then walk the parse result until the matching
    definition/call is found.
    
    For files with a large number of tests, this is fairly onerous and can
    dominate the test runtime. Fortunately, we can parse the file once and
    cache the starts and ends of every def/call node.
    This beings the `definition_for` runtime down from seconds to low
    milliseconds.
    
    We also see a reduction in gc time that is probably attributable to
    not repeatedly parsing the file.
    For a test run in an 240 test file that went from 11s of parsing to
    20ms, gc went from 4.5-2.2 seconds.
    
    Finally, for any user that has written a reporter or otherwise hooked
    into the filters, this should provide speedup as well.
    
    Co-authored-by: default avatarStath Stivaros <stath.stivaros@shopify.com>
Loading