Project

General

Profile

Actions

Backport #2723

closed

$: length affects re-require time of already loaded files

Added by ghazel (Greg Hazel) about 14 years ago. Updated over 6 years ago.

Status:
Rejected
[ruby-core:28113]

Description

=begin
This occurs on 1.8.6, 1.8.7 and 1.9.1.

The Kernel#require docs say: 'A feature will not be loaded if it‘s name already appears in $"."'. However, re-requiring the same file still scans all the load paths in $: even if the file will not be loaded.

This is exceedingly problematic on Windows, where stat()ing the list of all paths becomes very slow very quickly:

$:.length: 9, 0.005000 seconds
$:.length: 12, 0.005690 seconds
$:.length: 21, 0.010520 seconds
$:.length: 48, 0.022430 seconds
$:.length: 129, 0.062840 seconds
$:.length: 372, 0.179510 seconds
$:.length: 1101, 0.517070 seconds

Since it is not possible to create a new file called "set.rb" (or even "set.so", "set.o" and "set.dll" etc) somewhere else in the load path and have "require 'set'" pickup that new file, is it really necessary to scan the paths?

Specifying "require 'set.rb'" by hand works quickly.

$:.length: 9, 0.000030 seconds
$:.length: 12, 0.000030 seconds
$:.length: 21, 0.000030 seconds
$:.length: 48, 0.000030 seconds
$:.length: 129, 0.000030 seconds
$:.length: 372, 0.000030 seconds
$:.length: 1101, 0.000030 seconds

But it is very unlikely everyone will switch their require lines.

There are many solutions to this problem, depending on what the intended behavior is. The current solution is a significant source of wasted time when requiring a large code base. My application takes 20 full seconds of require time which are eliminated by hacking this extra scan step out. ($:.length == 169, $".length == 993)
=end


Related issues 1 (0 open1 closed)

Related to Ruby master - Feature #3010: slow require gems in ruby 1.9.1Closeddrbrain (Eric Hodel)03/25/2010Actions
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0