ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: burke@libbey.me
To: ruby-core@ruby-lang.org
Subject: [ruby-core:81460] [Ruby trunk Feature#13378] Eliminate 4 of 8 syscalls when requiring file by absolute path
Date: Mon, 29 May 2017 18:56:06 +0000	[thread overview]
Message-ID: <redmine.journal-65163.20170529185606.96ae7e6dc240d4af@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-13378.20170328194610@ruby-lang.org

Issue #13378 has been updated by burke (Burke Libbey).

File 0001-reduce-syscalls-on-require-v2.patch added

Thank you for the feedback! I've attached an updated patch to address the issues.

As for testing it, I haven't been able to think of a reasonable method to verify the behaviour without using dtrace/strace, since the only observable effect without system-level instrumentation should be a slight reduction in runtime. I *could* add a case to `DTrace::TestRequire`, but it feels wrong, since this file is concerned with testing the dtrace probes implemented by ruby, not testing ruby using built-in dtrace probes.

Suggestions?

----------------------------------------
Feature #13378: Eliminate 4 of 8 syscalls when requiring file by absolute path
https://bugs.ruby-lang.org/issues/13378#change-65163

* Author: burke (Burke Libbey)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
----------------------------------------
Don't open file twice when specified by absolute path.

When invoking `require '/a.rb'` (i.e. via an absolute path), ruby generates this sequence of syscalls:

    open    /a.rb
    fstat64 /a.rb
    close   /a.rb
    open    /a.rb
    fstat64 /a.rb
    fstat64 /a.rb
    read    /a.rb
    close   /a.rb

It is apparent that the only inherently necessary members of this sequence are:

    open    /a.rb
    fstat64 /a.rb
    read    /a.rb
    close   /a.rb

(the fstat64 isn't *obviously* necessary, but it does serve a purpose and probably shouldn't be removed).

The first open/fstat64/close is used to check whether the file is loadable. This is important when scanning the `$LOAD_PATH`, since it is used to determine when a file has been found. However, when we've already unambiguously identified a file before invoking `require`, this serves no inherent purpose, since we can move whatever work is happening as a result of that `fstat64` into the second open/close sequence.

This change bypasses the first open/fstat64/close in the case of an absolute path to `require`. It also removes one of the doubled-up `fstat64` calls later in the sequence. As a result, the number of syscalls to require a file changes:

* From 8 to 4 when specified by absolute path;
* From 5+3n to 4+3n otherwise *(where n is the number of `$LOAD_PATH` items scanned)*.

In future work, it would be possible to re-use the file descriptor opened while searching the `$LOAD_PATH` without the close/open sequence, but this would cause some ugly layering issues.

---

*We intend to use this in conjunction with something like https://github.com/shopify/bootscale, which pre-resolves required features to absolute paths before calling `require`. This change reduces our total number of filesystem accesses by 13% during application boot.*

*Various notes and rationale at http://notes.burke.libbey.me/ruby-require-optimization*

---Files--------------------------------
0001-reduce-syscalls-on-require.patch (7.56 KB)
0001-reduce-syscalls-on-require-fixed.patch (6.94 KB)
0001-reduce-syscalls-on-require-v2.patch (6.44 KB)


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

  parent reply	other threads:[~2017-05-29 18:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-13378.20170328194610@ruby-lang.org>
2017-03-28 19:46 ` [ruby-core:80437] [Ruby trunk Feature#13378] Eliminate 4 of 8 syscalls when requiring file by absolute path burke
2017-03-28 20:31 ` [ruby-core:80438] " burke
2017-05-26 18:32 ` [ruby-core:81397] " naruse
2017-05-29 18:56 ` burke [this message]
2017-06-16  7:57 ` [ruby-core:81702] " ko1

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-65163.20170529185606.96ae7e6dc240d4af@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).