Issue #19538 has been updated by byroot (Jean Boussier). So the example that sparked the idea was SHAPE_TOO_COMPLEX. It would be useful to emit a warning such as: `warning: SomeClass has too many shapes`. Other potential ideas could be to warn when constant caches are invalidated, or thing like that. However there is probably a complicated balance to find between relevance and verbosity. ---------------------------------------- Feature #19538: Performance warnings https://bugs.ruby-lang.org/issues/19538#change-102458 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- Suggested by @Eregon. There are program behaviors that are supported, but that we know aren't good for performance, however it's hard for users to know about them. Now that we have warning categories, we could add a `:performance` category to allow the VM to emit warning in some situations. The category would be disabled by default, and users interested in optimizing their program could turn it on in development. ```ruby Warning[:performance] = true ``` -- https://bugs.ruby-lang.org/

Issue #19538 has been updated by Eregon (Benoit Daloze). From investigating some benchmark today, I think it would be valuable to (opt-in of course) performance warn for: * uncached method lookup (i.e., the inline cache gave up, it saw too many different `obj->klass` at a call site) * singleton class creation on non-module objects (i.e., on instances). They basically cause the above, but being able to know where the singleton class is created is quite valuable and not easy to find from an uncached call site. Some amount of singleton classes on instances is fine though, the problem is if it's done repeatedly. If it's on a few global objects it's not problem, just like it's no problem on class/modules (as long as one doesn't create many classes/modules dynamically and use them at the same call site). Given the relation, I think warning for singleton class creation probably deserves a different opt-in mechanism, it's more like debugging aid for uncached method lookup (which are pretty much always bad for performance). One concern though is IIRC CRuby uses monomophic inline caches, so it would warn even for just 2 different classes seen at a call site. That seems too aggressive. TruffleRuby uses a limit of 8 which is probably too high but at least if we see more than 8 classes at a call site that's fair to call it megamorphic and not polymorphic anymore. ---------------------------------------- Feature #19538: Performance warnings https://bugs.ruby-lang.org/issues/19538#change-102509 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- Suggested by @Eregon. There are program behaviors that are supported, but that we know aren't good for performance, however it's hard for users to know about them. Now that we have warning categories, we could add a `:performance` category to allow the VM to emit warning in some situations. The category would be disabled by default, and users interested in optimizing their program could turn it on in development. ```ruby Warning[:performance] = true ``` -- https://bugs.ruby-lang.org/

Issue #19538 has been updated by matz (Yukihiro Matsumoto). Adding `Warning[:performance] = true` is acceptable. Warning for `OBJ_TOO_COMPLEX_SHAPE_ID` is also acceptable. But warnings for singleton class creation is not acceptable (because it's unavoidable for specific use cases). Matz. ---------------------------------------- Feature #19538: Performance warnings https://bugs.ruby-lang.org/issues/19538#change-102754 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- Suggested by @Eregon. There are program behaviors that are supported, but that we know aren't good for performance, however it's hard for users to know about them. Now that we have warning categories, we could add a `:performance` category to allow the VM to emit warning in some situations. The category would be disabled by default, and users interested in optimizing their program could turn it on in development. ```ruby Warning[:performance] = true ``` -- https://bugs.ruby-lang.org/

Issue #19538 has been updated by nobu (Nobuyoshi Nakada). https://github.com/ruby/ruby/pull/7707 ---------------------------------------- Feature #19538: Performance warnings https://bugs.ruby-lang.org/issues/19538#change-102762 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- Suggested by @Eregon. There are program behaviors that are supported, but that we know aren't good for performance, however it's hard for users to know about them. Now that we have warning categories, we could add a `:performance` category to allow the VM to emit warning in some situations. The category would be disabled by default, and users interested in optimizing their program could turn it on in development. ```ruby Warning[:performance] = true ``` -- https://bugs.ruby-lang.org/

Issue #19538 has been updated by Eregon (Benoit Daloze). Thank you, makes sense. Of course these performance warnings might differ per Ruby implementation. I thought `-w` should enable them but it seems multiple people disagree, OK. What about megamorphic method lookup? I guess the problem there is CRuby has no way to detect that due to monomophic caches? CRuby can detect singleton class creation though. Maybe we could warn for singleton classes but only if it happens more than some threshold (e.g. 10) per superclass of that singleton class (and ignore it if superclass is Class). WDYT? ---------------------------------------- Feature #19538: Performance warnings https://bugs.ruby-lang.org/issues/19538#change-102772 * Author: byroot (Jean Boussier) * Status: Closed * Priority: Normal ---------------------------------------- Suggested by @Eregon. There are program behaviors that are supported, but that we know aren't good for performance, however it's hard for users to know about them. Now that we have warning categories, we could add a `:performance` category to allow the VM to emit warning in some situations. The category would be disabled by default, and users interested in optimizing their program could turn it on in development. ```ruby Warning[:performance] = true ``` -- https://bugs.ruby-lang.org/