[#91458] [Ruby trunk Feature#4475] default variable name for parameter — matz@...
Issue #4475 has been updated by matz (Yukihiro Matsumoto).
3 messages
2019/02/07
[ruby-core:91632] [Ruby trunk Bug#15625] Module#name performance has exponential-time worst case
From:
nelhage@...
Date:
2019-02-27 17:36:38 UTC
List:
ruby-core #91632
Issue #15625 has been reported by nelhage (Nelson Elhage).
----------------------------------------
Bug #15625: Module#name performance has exponential-time worst case
https://bugs.ruby-lang.org/issues/15625
* Author: nelhage (Nelson Elhage)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.6.1p33 (2019-01-30 revision 66950) [x86_64-darwin18]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
It's well-known (c.f #11119) that `Module#name` has poor performance on anonymous classes, due to searching the entire constant namespace of the VM.
However, we recently discovered that it's even worse than that. In the presence of aliased constants (e.g. `module M; end; Alias = M`), the `find_class_path` method actually searches every *path* to a given module (e.g. it will visit that module under both the `M` and `Alias` names). This can lead to exponential-time behavior in cases of repeated aliases. See the attached test case, where performance gets twice as slow with every additional layer of aliasing:
On my laptop:
```
user system total real
before 2.183899 0.012151 2.196050 ( 2.355187)
user system total real
a19 5.614596 0.024394 5.638990 ( 5.702878)
user system total real
a10 9.204399 0.052817 9.257216 ( 9.391010)
user system total real
a11 16.184035 0.060854 16.244889 ( 16.561101)
```
Our house style makes extensive use of aliases as an import-like mechanism to provide short names within a given scope. We discovered this bug while exploring an actual performance problem -- this is not just a theoretical report.
---Files--------------------------------
classname.rb (854 Bytes)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>