ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: merch-redmine@jeremyevans.net
To: ruby-core@ruby-lang.org
Subject: [ruby-core:99209] [Ruby master Bug#17031] `Kernel#caller_locations(m, n)` should be optimized
Date: Fri, 17 Jul 2020 23:09:20 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-86589.20200717230916.182@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-17031.20200714190729.182@ruby-lang.org

Issue #17031 has been updated by jeremyevans0 (Jeremy Evans).


Reviewing the related code in vm_backtrace.c, you are correct.  This occurs both for `caller` and `caller_locations`.  The entire internal backtrace object is generated by `rb_ec_backtrace_object`, and then passed to a function that looks at specific parts of it to generate the strings or Thread::Backtrace::Location objects.  To fix this would require changing the logic so that `rb_ec_backtrace_object` was passed the starting level and number of frames.

----------------------------------------
Bug #17031: `Kernel#caller_locations(m, n)` should be optimized
https://bugs.ruby-lang.org/issues/17031#change-86589

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
`Kernel#caller_locations(1, 1)` currently appears to needlessly allocate memory for the whole backtrace.

It allocates ~20kB for a 800-deep stacktrace, vs 1.6 kB for a shallow backtrace.
It is also much slower for long stacktraces: about 7x slower for a 800-deep backtrace than for a shallow one.

Test used:
```ruby
def do_something
  location = caller_locations(1, 1).first
end

def test(depth, trigger)
  do_something if depth == trigger

  test(depth - 1, trigger) unless depth == 0
end

require 'benchmark/ips'

Benchmark.ips do |x|
  x.report (:short_backtrace    )    {test(800,800)}
  x.report (:long_backtrace     )    {test(800,  0)}
  x.report (:no_caller_locations)    {test(800, -1)}
end

require 'memory_profiler'

MemoryProfiler.report { test(800,800) }.pretty_print(scale_bytes: true, detailed_report: false)
MemoryProfiler.report { test(800,  0) }.pretty_print(scale_bytes: true, detailed_report: false)
```

Found when checking memory usage on RuboCop.




-- 
https://bugs.ruby-lang.org/

  parent reply	other threads:[~2020-07-17 23:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14 19:07 [ruby-core:99169] [Ruby master Bug#17031] `Kernel#caller_locations(m, n)` should be optimized marcandre-ruby-core
2020-07-15 14:30 ` [ruby-core:99176] " eregontp
2020-07-15 16:11 ` [ruby-core:99180] " marcandre-ruby-core
2020-07-17 23:09 ` merch-redmine [this message]
2020-07-23 22:25 ` [ruby-core:99309] " merch-redmine
2020-08-12  7:14 ` [ruby-core:99565] " ko1
2020-08-12 18:50 ` [ruby-core:99572] " merch-redmine
2020-08-21 18:01 ` [ruby-core:99667] " merch-redmine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-86589.20200717230916.182@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).