From: ko1@atdot.net
To: ruby-core@ruby-lang.org
Subject: [ruby-core:81702] [Ruby trunk Feature#13378] Eliminate 4 of 8 syscalls when requiring file by absolute path
Date: Fri, 16 Jun 2017 07:57:16 +0000 [thread overview]
Message-ID: <redmine.journal-65392.20170616075716.75f5b02ad99e185c@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-13378.20170328194610@ruby-lang.org
Issue #13378 has been updated by ko1 (Koichi Sasada).
Assignee set to nobu (Nobuyoshi Nakada)
----------------------------------------
Feature #13378: Eliminate 4 of 8 syscalls when requiring file by absolute path
https://bugs.ruby-lang.org/issues/13378#change-65392
* Author: burke (Burke Libbey)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
* 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/
prev parent reply other threads:[~2017-06-16 7:57 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 ` [ruby-core:81460] " burke
2017-06-16 7:57 ` ko1 [this message]
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-65392.20170616075716.75f5b02ad99e185c@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).