[#70252] Re: [ruby-cvs:58640] nobu:r51492 (trunk): node.c: NODE_ALLOCA for ALLOCV — Eric Wong <normalperson@...>
Besides possible backwards compatibility, can we drop volatile
3 messages
2015/08/05
[#70257] [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI — ko1@...
Issue #11420 has been reported by Koichi Sasada.
11 messages
2015/08/06
[#70337] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/11
Nice. Thank you guys for looking into this.
[#70349] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
Btw, did you consider using flexible array to avoid extra malloc
[#70355] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Юрий Соколов <funny.falcon@...>
2015/08/12
I thought to suggest to embed hash_id_table directly into places when it is
[#70356] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— SASADA Koichi <ko1@...>
2015/08/12
On 2015/08/13 4:29, Юрий Соколов wrote:
[#70358] Re: [Ruby trunk - Feature #11420] [Open] Introduce ID key table into MRI
— Eric Wong <normalperson@...>
2015/08/12
SASADA Koichi <ko1@atdot.net> wrote:
[#70509] [Ruby trunk - Misc #11276] [RFC] compile.c: convert to use ccan/list — ko1@...
Issue #11276 has been updated by Koichi Sasada.
3 messages
2015/08/21
[#70639] the undefined behavior of an iterator if it is modified inside of the block to which it yields — Daniel Doubrovkine <dblock@...>
(this is my first time e-mailing list list, so apologies for any misstep :)
4 messages
2015/08/31
[ruby-core:70416] [Ruby trunk - Bug #11448] Requiring a given library may take 23x longer depending on `require` context
From:
hanmac@...
Date:
2015-08-17 08:43:10 UTC
List:
ruby-core #70416
Issue #11448 has been updated by Hans Mackowiak.
i think that has something to do that each required gem does increase the $=
LOAD_PATH,
and how longer the load path is, it takes more time to require something.
that what i think does explain it. (its sad but i dont know a better way)
hm i dont know, but would using require_relative like inside of active_supp=
ort reduce the average output? or does it maybe even increase it?
----------------------------------------
Bug #11448: Requiring a given library may take 23x longer depending on `req=
uire` context
https://bugs.ruby-lang.org/issues/11448#change-53824
* Author: Rafa=C3=ABl Blais Masson
* Status: Open
* Priority: Normal
* Assignee:=20
* ruby -v: ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-darwin14]
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN
----------------------------------------
I was trying to narrow down the longest things to require during Rails boot=
when I stumbled on this.
Add two lines in `securerandom.rb` in order to output the time taken to `re=
quire 'openssl'`:
~~~
# -*- coding: us-ascii -*-
begin
+ start =3D Time.now
require 'openssl'
+ puts Time.now - start
rescue LoadError
end
# =3D=3D Secure random number generator interface.
# ...
~~~
Now run a script containing just this:
~~~
require 'securerandom'
~~~
Average output: `0.038829`
But run a similar script that requires a higher-level library, like:
~~~
require 'action_mailer'
~~~
Average output: `0.907959`
This still measures the time taken to `require 'openssl'` only. Why is it 2=
3x times slower? Because it is nested within other `require` calls? When re=
quiring `action_mailer`, this is the tree of files required to get to `secu=
rerandom`:
~~~
require 'action_mailer'
require 'abstract_controller'
require 'active_support/rails'
require 'active_support/deprecation'
require 'active_support/deprecation/behaviors'
require 'active_support/notifications'
require 'active_support/notifications/instrumenter'
require 'securerandom'
~~~
When starting one level down, time to `require 'openssl'` is cut in half:
~~~
require 'abstract_controller'
~~~
Average output: `0.465274`
--=20
https://bugs.ruby-lang.org/